| |
|
| |
| | Segment Routing Point-to-Multipoint Policy |
| |
| | draft-ietf-pim-sr-p2mp-policy-12.txt |
| | Date: |
23/05/2025 |
| | Authors: |
Dan Voyer, Clarence Filsfils, Rishabh Parekh, Hooman Bidgoli, Zhaohui Zhang |
| | Working Group: |
Protocols for IP Multicast (pim) |
|
Point-to-Multipoint (P2MP) policy enables creation of P2MP trees for efficient multi-point packet delivery in a Segment Routing (SR) domain. A SR P2MP Policy consists of Candidate Paths (CP) which define the topology of P2MP tree instances in each Candidate Path. A P2MP tree instance is instantiated by a set of Replication segments. This document specifies the architecture, signaling, and procedures for SR P2MP Policies within Segment Routing over MPLS (SR-MPLS) and Segment Routing over IPv6 (SRv6) dataplane. It defines the P2MP Policy construct, the roles of the root and leaf nodes, Candidate Paths and and how P2MP trees using Replication Segments are instantiated and maintained. Additionally, it describes the required extensions for Path Computation Element (PCE) to support P2MP path computation and provisioning. |
| | PIM Backup Designated Router Procedure |
| |
| | draft-ietf-pim-bdr-03.txt |
| | Date: |
03/07/2025 |
| | Authors: |
Mankamana Mishra, Anuj Budhiraja, Joya Neema, Imed Romdhani, Gyan Mishra |
| | Working Group: |
Protocols for IP Multicast (pim) |
|
On a multi-access network, one of the PIM routers is elected as a Designated Router (DR). On the last hop LAN, the PIM DR is responsible for tracking local multicast listeners and forwarding traffic to these listeners if the group is operating in PIM-SM. In this document, we propose mechanisms to minimize traffic losses during DR re-election. This document introduces the concept of a Backup Designated Router on a shared LAN and a procedure to perform Delayed DR election. A backup DR on LAN would be useful for faster convergence, whereas a Delayed DR election would be useful for minimizing traffic losses when new routers join a LAN. |
| | P2MP Policy Ping |
| |
|
SR Point-to-Multipoint (P2MP) Policies are used to define and manage explicit P2MP paths within a network. These policies are typically calculated via a controller-based mechanisms and installed via a Path Computation Element (PCE). In other cases these policies can be installed manually via YANG modles or CLI. They are used to steer multicast traffic along optimized paths from a Root to a set of Leaf routers. This document defines extensions to Ping and Traceroute mechanisms for Segment Routing (SR) P2MP Policy with MPLS encapsulation to provide OAM (Operations, Administration, and Maintenance) capabilities. The proposed extensions enable operators to verify connectivity, diagnose failures and troubleshoot forwarding issues within P2MP Policy multicast trees. By introducing new mechanisms for detecting failures and validating path integrity, this document enhances the operational robustness of P2MP multicast deployments. Additionally, it ensures that existing MPLS and SR-based OAM tools can be effectively applied to networks utilizing P2MP Policies. |
| | IGMP and MLD Snooping Yang Module Extension for L2VPN |
| |
|
Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping could be used in both bridge service and L2VPN service. The old ietf-igmp-mld-snooping yang module just describes the bridge service. In this document we extend the existing ietf-igmp-mld- snooping yang module and make it could be used in L2VPN service. |
| | Multicast-only Fast Reroute Based on Topology Independent Loop-free Alternate (TI-LFA) Fast Reroute |
| |
| | draft-ietf-pim-mofrr-tilfa-14.txt |
| | Date: |
08/04/2025 |
| | Authors: |
Yisong Liu, Mike McBride, Zheng Zhang, Jingrong Xie, Changwang Lin |
| | Working Group: |
Protocols for IP Multicast (pim) |
|
This document specifies the use of Topology Independent Loop-Free Alternate (TI-LFA) mechanisms with Multicast Only Fast ReRoute (MoFRR) for Protocol Independent Multicast (PIM). The TI-LFA provides fast reroute protection for unicast traffic in IP networks by precomputing backup paths that avoid potential failures. By integrating TI-LFA with MoFRR, this document extends the benefits of fast reroute mechanisms to multicast traffic, enabling enhanced resilience and minimized packet loss in multicast networks. The document outlines an optional approach to implement TI-LFA in conjunction with MoFRR for PIM, ensuring that multicast traffic is rapidly rerouted in the event of a failure. |
| | Multicast Lessons Learned from Decades of Deployment Experience |
| |
|
This document gives a historical perspective about the design and deployment of multicast routing protocols. The document describes the technical challenges discovered from building these protocols. Even though multicast has enjoyed success of deployment in special use-cases, this draft discusses what were, and are, the obstacles for mass deployment across the Internet. Individuals who are working on new multicast related protocols will benefit by knowing why certain older protocols are no longer in use today. |
| | Zeroconf Multicast Address Allocation Problem Statement and Requirements |
| |
|
This document describes a network that requires unique multicast addresses to distribute data. Various challenges are discussed, such as the use of multicast snooping to ensure efficient use of bandwidth, limitations of switch hardware, problems associated with address collisions, and the need to avoid user configuration. After all limitations were considered it was determined that multicast addresses need to be dynamically-assigned by a decentralized, zero- configuration protocol. Requirements and recommendations for suitable protocols are listed and specific considerations for assigning IPv4 and IPv6 addresses are reviewed. The document closes with several solutions that are precluded from consideration. |
| | Updates to Dynamic IPv6 Multicast Address Group IDs |
| |
|
Describes limitations of the existing range of dynamic IPv6 multicast addresses specified in RFC3307. Recommends replacing these allocations with a new registry in the IPv6 Multicast Address Space Registry registry group. Suggests initial contents of the new registry: a reduced allocation for MADCAP (RFC2730) and solicited- node multicast addresses (which were not previously noted in RFC3307). |
| | Group Address Allocation Protocol (GAAP) |
| |
|
This document describes a design for a lightweight decentralized multicast group address allocation protocol (named GAAP and pronounced "gap" as in "mind the gap"). The protocol requires no configuration setup and no centralized services. The protocol runs among group participants which need a unique group address to send and receive multicast packets. |
| | Host Extensions for IP Multicasting and "Any Source Multicasting" (ASM) IP service |
| |
|
This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support IP multicast with the IP service interface "Any Source Multicast" (ASM). This specification applies to both versions 4 and 6 of the Internet Protocol. Distribution of this memo is unlimited. This document replaces RFC1112 for everything but its specification of the IGMP version 1 protocol. |
| | Zero-Configuration Assignment of IPv6 Multicast Addresses |
| |
|
Describes a zero-configuration protocol for dynamically assigning IPv6 multicast addresses. Applications randomly assign multicast group IDs from a specified range and prevent collisions by using Multicast DNS (mDNS) to publish records in a new "eth-addr.arpa" special-use domain. This protocol satisfies all of the criteria listed in draft-ietf-pim-zeroconf-mcast-addr-alloc-ps. |
| | Yang Data Model for EVPN multicast |
| |
|
This document describes a YANG data model for EVPN multicast services. The model is agnostic of the underlay as well as RFC 9251. This document mainly focuses on EVPN instance framework. |
| | Deterministic Upstream Neighbor Selection for PIM Joins |
| |
|
In densely interconnected networks, a PIM node may have many choices as to what upstream neighbor to send a JOIN message to, for a given source and group. This document describes a mechanism for multiple nodes (e.g., leaf nodes in a data center) to pick the same upstream node (e.g., spine node) to avoid redundant traffic flows. |