]> Futurewei Technologies USA

USA tte@cs.fau.de

PIM This document proposes experimentation to evaluate benefits and feasibility of an IPv6 routing extension header based architecture, implementation and deployment of stateless IPv6 multicast specifically for IPv6 only networks using SRv6 for IP unicast. This experimentation intends to explore options to support easier proliferation of technologies developed by BIER-WG by providing an IPv6/SRv6 network optimized packet header and per-hop forwarding mechanisms than BIERin6. It also discusses how this work related to exploring advanced in-packet tree encoding mechanisms for both IPv6/SRv6 networks as well as BIER networks as a related effort.

Overview This document proposes experimentation to evaluate benefits and feasibility of an IPv6 routing extension header based multicast forwarding. Experimentation should include implementation and experimental deployment to evaluate the feasability and benefits of this approach for IPv6 only networks, especially those using SRv6 for unicast compared to alternative approaches such as using . This document is mostly meant to be a process document to vet support for the direction, and if that exists, it would be followed up by an appropriate IPv6 extension header draft proposal as well as other deemed necessary documents, such as an architectural document to describe howto apply the SRv6 SID semantic to the addresses used (or indicated) vby the IPv6+extension header for stateless multicast. The new IPv6 routing extension header would initially be using using one or two of the Experiment Routing Types (253, 254). Upon successfull completion of experimentation, assignment of a permanent Routing Type could be requested. The new routing extension header should inherit all re-useable aspects of the pre-existing unicast routing headers (RPL source route header and SRH), so that no unnecessary re-invention of already applicable SRv6 technology is done. Likewise, the new routing extension header should in one option explore how to best re-use the IETF BIER established stateless multicast forwarding architecture, while also complying to , and only exceeding it, when seen beneficial. Experimentation is also meant to investigate how multiple different encodings of the stateless multicast forwarding information could best be encoded in such multicast routing extension header options; these are henceforth called MRH - Multicast Routing Header. For example, different encodings could use different Routing Type code points as used for example across the different compressed unicast routing header options such as CRH-16, CRH-32. In another option, different encoding options could be selected from a further code-point within a single MRH Routing Type header. The experimentation should include two different encoding options. One is the aforementioned architecture based stateless multicast forwarding information (bitstring plus metadata). The second encoding should be an initial proposed encoding for stateless tree encoding within the MRH, such as derived from, but not necessarily . Note that like also in unicast SRv6 and its various forms of compressed routing header options, ultimtely different type of networks may prefer different encodings for multicast, and hence ensuring the design for extensibility is one core goal of this experimentation. This document does not (yet) propose an exact list of target documents required to perform the experiment or which WG it should best happen, but observes the following: 6MAN-WG is the responsible working group for IPv6 extension headers, but it requires a show of sufficient demand for the extension header in technology cases like this. One of the goals of the initial work with 6MAN-WG should be to determine how much of the encoding variations could be done without repeated work for 6MAN-WG, but instead by only work of the more expert work for such encodings, such as BIER. This would follow the logic, by which different semantics of QoS information in the DSCP field where also not performed by 6MAN-WG but other working groups (such as TSVWG). SPRING-WG is the overall responsible WG for the IPv6/SRv6 archtiecture as well as its unicast forwarding designs. SPRING-WG has delegated responsibility for IPv6 multicast aspects to PIM-WG. Hence this document is also positioned for PIM-WG for first considerations. BIER-WG is the working group which has introduced stateless multicast replication to the IETF, and where all the experience with hardware forwadrding implementation for stateless multicast replication exists. Given how the goal of this experimentation is to not re-invent any aspect of BIER-WG except for those aspects that will support better adoption of the technology to IPv6-only/SRv6 networks, it is highly desirable to involve BIER in any of the aspects of the experiment where this expertise can be drawn upon and where consistency with existing BIER approaches needs to be vetted. New encoding options for stateless multicast forwarding should not only be defined for encapsulation within an IPv6 MRH, but if BIER-WG is also interested in that encoding, then the encoding should be specified agnostic to header encoding, such that it could support encapsulation both into IPv6/MRH as well as BIER/ headers.

Background: The road towards BIER This background section is intended as an overview to motivate why operators have shown interest in an IPv6/SRv6-SRH aligned solution for stateless multicast for many operational reasons, and why BIER-WG did arrive at a different conclusion for technology when adopting . This is written in the hope that the experimentation proposed by this document is understood as a complementary technology that is ultimately meant to proliferade the BIER-WG spearheaded technology into more markets with minimum additional standardization and development effort. Before BIER, multicast solutions where defined as extensions of the unicast (inter)network solution run in the network. RFC1112 defined IP Multicast which re-used IPv4 () packet headers and added multicast semantic through a range of dedicated-to-multicast IPv4 destination adress range. IPv6 kept this architecture but already included it in . In result, so-called dual-plane IPv4/IPv6 network did also have to run dual-plane IPv4/IPv6 multicast. In networks that only could or wanted to run a single version of IP, solutions for encapsulation of one version over the other also exist for both unicast and multicast. In MPLS networks, initially IP multicast was run by using IPv4 multicast in parallel to MPLS for unicast, but operators expected that the protocol stack for multicast both in the forwarding plane as well as the control plane was adjusted to leverage the same protocols as for MPLS unicast, so that at least in name the variety of protocols that needed to be run in the network for unicast and multicast was not increased over an MPLS unicast only network. Even though implementations of PIM for an MPLS forwarding plane already existed since 1998, the PIM approach was explicitly not choosen because this was a protocol unfamiliar to MPLS network operators. Instead, the industry and thereafter the IETF chose to embed the necessary multicast functionality into the dominant MPLS unicast protocols LDP and RSVP-TE. This resultet in mLDP (multicast LDP) and RSVP-TE/P2MP (Point to Multipoint). Likewise, PIM overlay signaling for multicast VPN services was also re-invented due to operator demand by bringing similar multicast group membership signaling into BGP, thus allowing service providers to completely run on only BGP and IGP but without PIM for multicast. Whether the forwarding plane uses IPv4/IPv6 or MPLS. This was done even though no other than operational reasons of familiary by operators with BGP where brought forward versus the already well deployed option of using PIM for overlay signaling in those VPN solutions. While this approach of having the multicast solution be embedded in the networks unicast solution does have a wide range of benefits, it also came with downsides. When classical MPLS solutions with LDP where superceeded by SR-MPLS network solution for unicast, this was also done to eliminate LDP from the network, which had a range of problems co-existing with unicast IGPs, and/or arguably unnecessary complexity and duplication of protocol state. But in the wake of this unicast network architecture evolution towards unicast SR-MPLS, operators also asked to eliminate multicast MPLS using mLDP and RSVP-TE/P2MP. More fundamentally, multicast solutions including all the aforementioned ones are based on explicit multicast tree state, which is managed hop-by-hop in the network. This is completely contrary to what operators are used to do with MPLS or IP unicast. In unicast, the network, especially the transit nodes (called P-nodes in service provider networks) only carry topology state (routing tables), but not state belonging to or influenced by individual subscribers of the network. Subscribers may send arbitrary traffic, but that will not impact the IP/MPLS unicast routing tables on P-nodes. In IP/MPLS multicast, this is not the case. When a subscriber starts multicast sender and receiver applications, then they will cause mLDP, PIM or BGP signaling to propagate through the network including transit service provider hops and ultimately create multicast tree state, which is similar in nature to unicast routing tables: It requires hardware forwarding resources that can get exhausted, and it requires control plane activity that may put undesirable load onto the control plane CPU not only during creation or change of the applications, but even more so during reconvergence due to topological changes in the network (failures, recoveries). While advanced multicast VPN protocol options do allow service providers to put bounds on this state (I-PMSI state and aggregated S-PMSI state), this too is causing additional complexity and diagnostic/troubleshooting overhead. Even when there is no misbehavior in the network, keeping track and troubleshooting multicast state hop-by-hop in the network can be a real operational challenge, and even with aforementioned multicast VPN mechanisms in place, it still is the equivalent of having unicast (BGP) VPN subscriber routing table entry related state on P-routers, whereas in unicast those P-routers only carry a completetely subscriber agnosted IGP routing table. In result of all these operational experiences by operators, several of them opted to move from their prior (stateful) multicast solution to one where there would be no multicast state at all across the service provider core network, instead replicating multicast traffic on the ingress PE as unicast traffic, one copy each to each egress PE that required the packet. This was much later standardized as (). This is called "multicast ingress replication" BIER was invented out of the early recognition of these operational challenges and in fear that the non-scalability of multicast ingress replication would ultimately lead to the demise of solutions relying on network based multicast. The BIER architecture, defines a mechanism by which a packet header which includes a bitstring and associated metadata can source-route and replicate the packet hop-by-hop across P-routers to a set of egress (PE) routers using only the same type of of routing information as already present in a service provider network - addressing information for the core networks P/PE routers specific to BIER, but not to any subscriber information. With BIER, no multicast tree state ever needs to exist on the transit (P) routers. The BIER technology also makes it easy to evolve from multicast ingress replication solutions, by simply adding the BIER to the P/PE routers and letting the ingress router determine the BIER header bitstring instead of creating a separate copy per packet to each required PE. Even partial deployment of BIER across P/PE routers is well considered in the BIER architecture and feasible automastically without additional provisioning, albeit this is likely not fully supported by existing implementations today. The BIER architecture does not specify the way such a BIER header was to be packetized. Initially during the work on BIER it was seen as a real possibility to create per-unicast-network-design encapsulations as it was done in before for IPv4/IPv6 and MPLS. Nevertheless, when work towards the first BIER encapsulation(s) progressed, it became obvious that the definition of multiple different encapsulations was at the non-mature and non-adopted state of the technology too ambitious and time consuming (note that the same may be said about the current evolution towards multiple comprssed unicast routing headers). Instead, BIER-WG chose an approach where the metadata required for different type of networks was coalesced into a single BIER header approach, which ultimately became - "Encapsulation for BIER in MPLS and Non-MPLS Networks". This header includes a DSCP field for use in IP network, and the first 32 bits mimic exactly a 32-bit word of an MPLS stack. When BIER packets are propagated through an MPLS network, there is no end-to-end MPLS label stack or even MPLS "packet" in that BIER packet. Logically the per-hop BIER forwarding happens solely at the BIER layer, and on every hop the packet is encapsulated into a single-LSE MPLS frame. In a network with full BIER support, where BIER routers are L2 adjacenty, this is functionally equivalent to simply encapsulate the BIER packet into an ethernet frame with a BIER ethernet type. The core reasons for the MPLS encapsulation was the MPLS network operator preference to only see MPLS frames on the wires and the possible simplification of MPLS centric router hardware forwarding plane designs to demultiplex packets easier on an LSE than on an ethertype. An actual functional benefit of the MPLS encapsulation exists, in a partial deployment, when the next BIER router is not L2 adjacent, and the MPLS label could for example be an SR-MPLS label to the closest BIER capable router. As a result of this originally "optimized-for-MPLS" approach, architecturally marked for BIER the desire to embrace an approach where the BIER multicast solution should be seen as a "one-size-fits-all" multicast network designs: To avoid the problem that any change/evolution in unicast forwarding technologies would create undesirable asks for change in the multicast technology - and hence cause unnecessary technology churn. Of course, this approach for the BIER forwarding plane does not prevent possible churn on the necessary BIER control plane. If for example use of IGP in networks (as is the standard today in SR networks) should fall out of fashion, and would be replaced by some (maybe AI controlled ?) SDN-controller control plane, then the same would be necessary also for BIER.

BIER for IPv6 networks Operators of IPv6-only networks using SRv6 for unicast traffic steering and service management expressed interest in adopting stateless source-routed technologies for multicast across their networks. The BIER architecture was the obvious starting point to provide this functionality. Additional service requirements such as traffic engineering could be solved via BIER extensions such as BIER-TE () without IPv6 specific changes required. Some SRv6 networks are amongst the largest Service Provider networks in the world, hence there is likely going to be more of an upper-end scaling evaluation to be done for SRv6 networks. However, the core challenge for IPv6-only network operators comes through the "one-size-fits-all" model adopted via by BIER. By itself, this RFC is insufficient to operate BIER in a network without MPLS. For this reason, (BIERin6) defines how to operate BIER in an IPv6 only network based on the requirements stated in . This approach repeats the MPLS network approach for BIER in IPv6 networks: end-to-end forwarding is via an BIER header and BIER hop-by-hop an IPv6 specific IPv6 "tunnel" header can be added if that is so desired, to make the packet appear as IPv6 on the wire. In a full deployment those L2 IPv6 encapsulations could even use link-local IPv6 addresses. In addition, the encoding and control plane signaling of the BIER metadata that needs change from its MPLS bindings also requires new drafts, and .

Challenges of BIER with IPv6

Oerational, architectural, performance The main challenge is that the requirements that lead to BIERin6 did not take the operational and architectural preferences of operators running IPv6-only networks into account by replicating the model developed with primarily MPLS in mind. For operators of IPv6/SRv6 networks, BIERin6 marks a significant departure from their unicast IPv6 network architecture and operations. One key difference between IPv6 and MPLS designs is that the cost of headers and encap/decap. When operators in an IPv6 network expect for operational reasons to see only IPv6 packets on the wire, the BIERin6 approach would require per-L2-hop additional IPv6 tunnel encapsulations, which is a significant overhead, whereas the MPLS equivalent is no additional encapsulation overhead at all, because the BIER header itself already start with a 32 bit word that serves as an MPLS LSE and single-entry label stack to demultiplex to BIER. If instead (as proposed to be experimented in this document), the approach of IPv6 extension header source-routing was used, then this additional IPv6 per-hop encapsulation header was not required, but the end-to-end IPv6 header (plus extension header) that is always required would suffice. Note too, that this difference also holds true, when there is only a partial deployment of stateless multicast replication capable routers, because by virtue of the pre-existing end-to-end IPv6 header and defined forwarding rules, the forwarding across non-stateless-multicast-capable IPv6 routers would solely require forwarding based on the IPv6 destination address of the IPv6 (base) header. In addition to overhead on the wire, different type of forwarding planes may also incur different degrees of performance loss when per L2-hop packets actually need to be decapsulated and re-encapsulated into link-local address IPv6 headers. Keeping an encapsulation IPv6 header and re-writing it hop-by with not only the destination address (as required by , but also the source-address might equally be a challenge if hardware is not specifically optimized for that. The author has the unfortunate experience with this type of hop-by-hop IPv6 tunneling in a completely different use-case domain, where it has served as the core obstacle to adoption (see ).

Architectural and functional While these differences between BIERin6 and extension header based approaches are mostly router-implementation, performance and operator preference, there is also a more fundamental issue with BIER which the proposed extension header resolves, and that is that the packet on the wire can not be identified as an IPv6 multicast packet, and hence the wide range of collateral forwarding plane functions that have already been defined in routers to manage IPv6 multicast traffic are not applicable or would require a lot more complex, variable length lookup of the IPv6 multicast destination address across protocol layer boundaries. These features are listed further below in the document. Another way to look at this functional difference is that BIER was designed to require an IP Multicast flow overlay so that BIER could - maybe similar to MPLS - be a common "L2.5" technology, whereas IPv6 multicast is designed as an end-to-end L3 technology just like IPv6 unicast, and the IPv6 extension header approach is the only obvious way to achieve this, and minimize or completely eliminate additional layering overheads necessary otherwise.

IETF process In the discussions about the best BIER for IPv6 network solution, one of the foremost argument by those in favor of BIERin6 was also explicitly to prove investment protection for those vendors who had already invested into and . While it certainly makes sense to support commercial goals in IETF, this specific ask was never admitted in any prior technology decision between MPLS and IPv6 solutions nor for other Multicast technologies (e.g.: introducing BGP instead of PIM overlay signaling was providing all the necessary functionality, or introducing MPLS multicast forwarding when many operators had deployed native IPv4 multicast in MPLS networks). Nor was it done in the case of other technologies, such as OSPF vs. IS-IS. Instead, if and when different competing designs existed due to customer demand, the IETF always tried to provide equally optimized solutions for each customer network type and let the market decide. While technically similar approaches may pose additional work in the IETF, they have typically always shown to be beneficial for the overall set of customers of IETF standards, broadening the scope of applicability to more candidate customers. The hope of this experimentation is equally that this would hold true for the proliveration of original BIER technoligies into IPv6/SRv6 only networks - more so than what BIERin6 alone could achieve (in the opinion of the author). Expecting for BIERin6 to make BIER successfull in IPv6-only/SRv6 networks is a highly risky proposition and can easily result in less than more adoption of the technology. Hence this document proposes for the IETF to at least embrace experimentation with the IPv6 extension header based options which do provide the best technically and operational solutions for IPv6-only/SRv6 networks. Especially given the recent varied work on different unicast steering header options for SRv6 unicast, it seems highly unlikely that the industry could not endure an additional encoding alternative to for stateless multicast replication in IPv6 networks.

List of target benefits / directions The following is a candidate list of benefits/technical targets of the solutions The solution uses an IPv6 routing extension header in the same fashion as SRv6 unicast does this () for high-speed networks or for IoT networks. Ideally, it should be sufficient to have a single new IPv6 routing extension header for stateless multicast (instead of two for unicast for different networks). For operational safety, it seems prudent to allocate a new routing extension header code point so that this technology can be introduced into networks which already run either of the existing unicast extension headers without having to change any of the unicast specific fowarding plane code - because demultiplexing between unicast and multicast would already be able to happen at the extension header code point. If instead it is seen by IPv6 experts that it is equally safe and feasible to encode the information necessary for stateless multicast into the existing SRH extension header, using similar tricks to how compressed unicast steering is encoded (), and that this is preferrable, then this could of course equally be considered. All forwarding should follow the and principles to the extend that they are applicable to packets that need to be replicated. This specifically means that on each steering or replication hop, the IPv6 header destination address gets rewritten by the next steering/replication hop IPv6 address ("SID") derived from the extension header. While application software stacks for other network protocols beside IP do exist, they are by far not as widely and easily accessible across wide ranges of platforms/operating systems. use of IPv6 extension headers is the likely most easy proliferable solution to bring stateless multicast replication into the software realm. This is not only useful for softwareization of traditional routers with new implementations, or decomposition thereof into network function application code, but even more so for actual classical end-to-end applications using IP multicast. Enabling such applications, to solely rely on stateless multicast, for example in data centers is an explicit additional market space that this effort intends to support. To directly support the established IP multicast service interfaces of ASM and SSM, the extension header must support to directly indicate IP multicast. Technically this means that the extension header also needs to be able to carry an IPv6 mulicast destination address directly, namely when there is the need to indicate an IPv6 multicast packet. This is a significant difference over SRv6 unicast and BIER. BIER specifically does support IP multicast only in the way MPLS does it: as an L2.5 underlay, which can encapsulate an IP multicast packet. The stateless IPv6 multicast solution intends to avoid this duplication of IPv6 header when it is used end-to-end. With this architecture, IPv6 multicast applications could be made to rely on stateless IPv6 multicast if the socket/network layer in the multicast hope can simply insert the routing extension header indicating the stateless distribution tree - without the need for any additions IPv6 in IPv6 encapsulations or other complexity. This for example could easily be something to make deployment of IPv6 multicast easier in data center encvironments where the extension header data could be requested from and provided by a network controller. Carrying the IPv6 multicast destination address in a fixed offset part of an IPv6 extension headers makes it possible (at somewhat higher parsing cost) to maintain traditional operational benefits of IP multicast: It allows per-hop operation of IP specific forwarding plane features: IP multicast IPfix for accounting, billing and performance quality troubleshooting IP multicast group address (range) derived QoS handling (common in several network and well matching "programming" goals). IPmulticast group range derived accounting, billing, policiing or other policies.

Intial proposed MRH definitions

MRH Header This chapter gives a non-normative idea of how the extension header structures to be defined by the experiment could look like

The actual "Multicast Routing Header" is identified by one "Routing Type" value. If multiple encodings ("MRH Sub-Type") are required, then multiple "Routing Types" would need to be assigned (for experimentation only two are available), or instad, a new "MRH Sub-Type" demultiplexer field could be defined. With a worst-case small number of different MRH Sub-Types of maybe <=5 required, it may be deemed appropriate by 6MAN-WG to allocate up to e.g.: four Routing Types before requiring a Sub-Type encoding to avoid Routing Type exhaustion. "Segments Left" was defined by . It may not actually be useful in all encodings, so one of the experimentation question is whether it would be acceptable to avoid wasting this space if it is not needed, or to reuse it for a more appropriate purpose. The "MSER-Segment" ("Multicast Source Exit Router Segment") can carry the IPv6 multicast packets destination address. This is necessary when an MRH is to be used to carry an actual IPv6 Multicast packet. Alternatively, this MSER-Segment can carry a non-IPv6 multicast group range IPv6 address. In this case it is a group-SID, indicating for example programmability parameters to the receivers. When deploying MRH with BIER-like overlays, the MSER Segment may not be required. If one wanted to avoid wasting those 128 bits for such use-cases, then appropriate encoding options should be found (different Routing Type). However, one of the big benefits for IPv6 from using MRH (as opposed to a BIER header) could come from the ability to always have this destination IPv6 address present in a fixed location in the IPv6 (extended) header to trigger various collateral forwarding plane functions, as mentioned elsewhere in this document. Therefore, the functional (not performance) preference would be to always include this field. Likewise, in many applications a "shared IPv6 SID" for all receivers of the packet seems likely very useful, even if its semantic is not that of an IPv6 multicast group address. The "MRH Sub-Type specific data" if present may carry the encoding for a particular method of stateless IPv6 multicast forwarding

BIER MRH Sub-Type format

is an example initial proposal for encoding of BIER (and BIER-TE, ) into an MRH Sub-Type. Most of the signaling elements of the BIER header are not required: BFIR-id is not required because in an IPv6 environment, the IPv6 (base) header IPv6 source address (which can be a SID) serves the same purpose. If necessary to maintain existing signaling for 16-bit BFR-ID values, then an appropriate SID format for the 128 bit address with such a 16 bit field can be specified. Likewise, TTL, DSCP and Ver fields are not required as they already exist in the IPv6 header. The Proto field is not required, because the "Next Header" field in the MRH serves the same purpose. Nibble, TC and S fields are not required because they are artefacts of the BIER header for MPLS. The remaining signaling elements keep their existing semantic but are slightly different encoded: proposes to encode BSL, SD and SI into the BIFT-id field. This proposal picks up the same encoding, eliminating therefore also the separate BSL field. OAM is maintained unchanged. BitString is maintained unchanged. Entropy is shortened to allow fitting the non-bitstring signaling elements into 32 bits. 1024 different path options are more than enough, so no functional deterioration is expected.

Further MRH Sub-Type considerations The encoding for other "MRH Sub-Type specific data" fields are not presented here. For example, if RTS ( was used as a Sub-Type, then that field would be encoded according to that drafts header, specified in , section 4.3. Independent of MRH Sub-Type, the per-hop forwarding rules need to be specified, should be the same as IPv6 unicast source routing: Every hop determines for every packet copy a next-hop ipv6 next-hop address, which will be copied into the IPv6 header destination address field. Different from IPv6 unicast, the different MRH Sub-Type encodings will require different modifications to the MRH header. In the BIER Sub-Type case for example, bits in the Bitstring need to be cleared. In headers such as RTS, it may be necessary to update two index fields in the Sub-Type data to indicate to the next-hop the active part of the Sub-Type header that needs to be parsed. This is equivalent to the Segments-Left field in IPv6 unicast routing header cases.

This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK] In Low-Power and Lossy Networks (LLNs), memory constraints on routers may limit them to maintaining, at most, a few routes. In some configurations, it is necessary to use these memory-constrained routers to deliver datagrams to nodes within the LLN. The Routing Protocol for Low-Power and Lossy Networks (RPL) can be used in some deployments to store most, if not all, routes on one (e.g., the Directed Acyclic Graph (DAG) root) or a few routers and forward the IPv6 datagram using a source routing technique to avoid large routing tables on memory-constrained routers. This document specifies a new IPv6 Routing header type for delivering datagrams within a RPL routing domain. [STANDARDS-TRACK] This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The details of the encapsulation depend on the type of network used to realize the multicast domain. This document specifies a BIER encapsulation that can be used in an MPLS network or, with slight differences, in a non-MPLS network. This document specifies a new architecture for the forwarding of multicast data packets. It provides optimal forwarding of multicast packets through a "multicast domain". However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state. This architecture is known as "Bit Index Explicit Replication" (BIER). When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The procedures for forwarding a packet based on its BIER header are specified in this document. Elimination of the per-flow state and the explicit tree-building protocols results in a considerable simplification. Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. RFCs 6513, 6514, and other RFCs describe procedures by which a Service Provider may offer Multicast VPN (MVPN) service to its customers. These procedures create point-to-multipoint (P2MP) or multipoint-to-multipoint (MP2MP) trees across the Service Provider's backbone. One type of P2MP tree that may be used is known as an "Ingress Replication (IR) tunnel". In an IR tunnel, a parent node need not be directly connected to its child nodes. When a parent node has to send a multicast data packet to its n child nodes, it does not use Layer 2 multicast, IP multicast, or MPLS multicast to do so. Rather, it makes n individual copies, and then unicasts each copy, through an IP or MPLS unicast tunnel, to exactly one child node. While the prior MVPN specifications allow the use of IR tunnels, those specifications are not always very clear or explicit about how the MVPN protocol elements and procedures are applied to IR tunnels. This document updates RFCs 6513 and 6514 by adding additional details that are specific to the use of IR tunnels. Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing and be as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations, Administration, and Management (OAM) communications over a network that provides automatically configured, hop-by-hop authenticated and encrypted communications via automatically configured IPv6 even when the network is not configured or is misconfigured. The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. This memo describes per-packet stateless strict and loose path steered replication and forwarding for "Bit Index Explicit Replication" (BIER) packets (RFC 8279); it is called "Tree Engineering for Bit Index Explicit Replication" (BIER-TE) and is intended to be used as the path steering mechanism for Traffic Engineering with BIER. BIER-TE introduces a new semantic for "bit positions" (BPs). These BPs indicate adjacencies of the network topology, as opposed to (non-TE) BIER in which BPs indicate "Bit-Forwarding Egress Routers" (BFERs). A BIER-TE "packets BitString" therefore indicates the edges of the (loop-free) tree across which the packets are forwarded by BIER-TE. BIER-TE can leverage BIER forwarding engines with little changes. Co-existence of BIER and BIER-TE forwarding in the same domain is possible -- for example, by using separate BIER "subdomains" (SDs). Except for the optional routed adjacencies, BIER-TE does not require a BIER routing underlay and can therefore operate without depending on a routing protocol such as the "Interior Gateway Protocol" (IGP). When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified, and it describes the numbers that have already been reserved by other documents. [STANDARDS-TRACK] Futurewei Technologies USA Huawei 2012 NT Lab Huawei 2012 NT Lab Huawei 2012 NT Lab Huawei 2012 NT Lab This document defines an encoding and corresponding packet processing procedures for native IPv6 multicast source routing (MSR6) using a so-called "Recursive Bitstring" (RBS) address structure. The RBS address structure encodes the source-routed multicast tree as a tree of bitstrings. Each router on the tree only needs to examine and perform replication for the one bitstring destined for it. The MSR6/RBS IPv6 extension header encoding and processing is modeled after that of unicast source routing headers, RFC6554 and RFC8754, and shares all elements that can be shared. To support the RBS structure, it is replacing the "Segments Left" pointer to the next segment with two fields to point to the next sub-tree to parse. Futurewei Technologies USA This draft summarizes additional personal opinions of the author for why existing stateless multicast solutions BIER/BIER-TE are not sufficient to support the operator, architecture and use-case goals that MSR6 proposes to solve. This document is complementary to problems outlined in I-D.liu-msr6- problem-statement and in no way affects any of them. Instead, it attempts to look more at lower-layer functional challenges of current stateless source routing multicast solutions (BIER/BIER-TE), as well as architectural, network and protocol design ecosystem requirements of operators. ZTE Corporation Juniper Networks Individual Cisco Systems Nokia Verizon BIER is a multicast forwarding architecture that does not require per-flow state inside the network yet still provides optimal replication. This document describes how the existing BIER encapsulation specified in RFC 8296 works in a non-MPLS IPv6 network, which is referred to as BIERin6. Specifically, like in an IPv4 network, BIER can work over L2 links directly or over tunnels. In case of IPv6 tunneling, a new IP "Next Header" type is to be assigned for BIER. Futurewei Technologies USA University of Tuebingen University of Tuebingen BIER provides stateless multicast in BIER domains using bitstrings to indicate receivers. BIER-TE extends BIER with tree engineering capabilities. Both suffer from scalability problems in large networks as bitstrings are of limited size so the BIER domains need to be subdivided using set identifiers so that possibly many packets need to be sent to reach all receivers of a multicast group within a subdomain. This problem can be mitigated by encoding explicit multicast trees in packet headers with bitstrings that have only node-local significance. A drawback of this method is that any hop on the path needs to be encoded so that long paths consume lots of header space. This document presents the idea of Segment Routed Recursive Tree Structures (RTS), a unifying approach in which a packet header representing a multicast distribution tree is constructed from a tree structure of vertices ("so called Recursive Units") that support replication to their next-hop neighbors either via local bitstrings or via sequence of next-hop neighbor identifiers called SIDs. RTS, like RBS is intended to expand the applicability of deployment for stateless multicast replication beyond what BIER and BIER-TE support and expect: larger networks, less operational complexity, and utilization of more modern forwarding planes as those expected to be possible when BIER was designed (ca. 2010). This document only specifies the forwarding plane but discusses possible architectural options, which are primarily determined through the future definition/mapping to encapsulation headers and controller-plane functions. Huawei Huawei Arrcus Cisco Systems, Inc. Juniper Networks. Huawei Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. BIER can be supported in MPLS and non-MPLS networks. This document updates RFC8296 and specifies the required extensions to the IS-IS, OSPFv2 and OSPFv3 protocols for supporting BIER in non- MPLS networks using BIER non-MPLS encapsulation. Futurewei Huawei Huawei Huawei Cisco China Telecom Verizon Inc. Juniper There have been several proposed solutions with BIER being used in IPv6. But there hasn't been a document which describes the problem and lists the requirements. The goal of this document is to describe the general BIER IPv6 encapsulation problem and detail solution requirements, thereby assisting the working group in the development of acceptable solutions. Individual Cisco Systems Alibaba Group Nokia Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. The Multicast packet is encapsulated using a BIER Header and transported through an MPLS or non-MPLS network. When MPLS is used as the transport, the Bit Indexed Forwarding Table (BIFT) is identified by a MPLS Label. When non-MPLS transport is used, the BIFT is identified by a 20bit value. This document describes one way of encoding the 20bit value. China Mobile Cisco Systems, Inc. Huawei Technologies Orange Cisco Systems, Inc. Segment Routing over IPv6 (SRv6) is the instantiation of Segment Routing (SR) on the IPv6 dataplane. This document specifies new flavors for the SRv6 endpoint behaviors defined in RFC 8986, which enable the compression of an SRv6 segment list. Such compression significantly reduces the size of the SRv6 encapsulation needed to steer packets over long segment lists. This document updates RFC 8754 by allowing a Segment List entry in the Segment Routing Header (SRH) to be either an IPv6 address, as specified in RFC 8754, or a REPLACE-CSID container in packed format, as specified in this document.

Changelog 00: initial version.

History This document is an evolution from the process whose last draft was . That informational draft covers in a more concise way two core problem areas The Desire and need for an IPv6 routing extension header based solution architecture for stateless IPv6 multicast source routing in support of IPv6/SSRv6-only networks. This is covered in P4...P7 and according explanationsj. The desire and need for an easier to operate and better to scale stateless replication mechanism instad of , such as proposals like or . These are covered in P1...P3,P8 and according explanations. Point 1 in that problem state document can be resolved by an IPv6 routing extension header based solution, which is what this document explains in more detail and proposes to introduce through experimental IETF work. It is thus overlapping with that problem statments P4...P7. Such an IPv6 routing extension header based solution can and should leverage both an based payload, which would allow a minimal change and new development from existing BIER specifciations, replacing only as the encapsulation and replacing the need for . Point 2 is not detailled in this document except to explain what aspects in the new IPv6 routing extension header are required to enable such alternative encodings compared to the existing BIER bitstring.