| |
|
| |
| | Segment Routing Point-to-Multipoint Policy |
| |
| | draft-ietf-pim-sr-p2mp-policy-10.txt |
| | Date: |
05/11/2024 |
| | Authors: |
Dan Voyer, Clarence Filsfils, Rishabh Parekh, Hooman Bidgoli, Zhaohui Zhang, Mankamana Mishra |
| | Working Group: |
Protocols for IP Multicast (pim) |
|
This document describes an architecture to construct a Point-to- Multipoint (P2MP) tree to deliver Multi-point services in a Segment Routing domain. A SR P2MP tree is constructed by stitching a set of Replication segments. A SR Point-to-Multipoint (SR P2MP) Policy defines a P2MP tree and a PCE computes and instantiates the tree. |
| | PIM Backup Designated Router Procedure |
| |
| | draft-ietf-pim-bdr-02.txt |
| | Date: |
20/10/2024 |
| | Authors: |
Mankamana Mishra, Anuj Budhiraja, Aravind Paramasivam, 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 a mechanism to elect backup DR on a shared LAN. A backup DR on LAN would be useful for faster convergence. This draft introduces the concept of a Backup Designated Router (BDR) and the procedure to implement it. |
| | Multicast Listener Discovery Version 2 (MLDv2) for IPv6 |
| |
|
This document updates RFC 2710, and it specifies Version 2 of the Multicast Listener Discovery Protocol (MLDv2). MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses. This document obsoletes RFC 3810. |
| | Internet Group Management Protocol,Version 3 |
| |
|
IGMP is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP adds support for source filtering, that is, the ability for a system to report interest in receiving packets only from specific source addresses, or from all but specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers. This document specifies Version 3 of the Internet Group Management Protocol, IGMPv3. It is a revised version of the specification to include clarifications and fixes for errata in RFC 3376 and is backwards compatible with RFC 3376. This document updates RFC 2236 and obsoletes RFC 3376. |
| | PIM Join/Prune Attributes for LISP Environments using Underlay Multicast |
| |
|
This document specifies an update to the PIM Receiver RLOC Join/Prune attribute that supports the construction of multicast distribution trees where the source and receivers are located in different Locator/ID Separation Protocol (LISP) sites and are connected using underlay IP Multicast. This attribute allows the receiver site to signal the underlay multicast group to the control plane of the root Ingress Tunnel Router (ITR). This document updates RFC 8059. |
| | P2MP Policy Ping |
| |
|
SR P2MP policies are set of policies that enable architecture for P2MP service delivery. A P2MP Policy consists of candidate paths that connects the Root of the Tree to a set of Leaves. The P2MP policy is composed of replication segments. A replication segment is a forwarding instruction for a candidate path which is downloaded to the Root, transit nodes and the leaves. This document describes a simple and efficient mechanism that can be used to detect data plane failures in P2MP Policy Candidate Paths (CPs) and Path Instances (PIs). |
| | 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 Fast Reroute |
| |
| | draft-ietf-pim-mofrr-tilfa-07.txt |
| | Date: |
08/10/2024 |
| | 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 mechanism is designed for standard link-state Interior Gateway Protocol (IGP) shortest path and Segment Routing (SR) scenarios. 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 the necessary protocol extensions and operational considerations to implement TI-LFA in conjunction with MoFRR for PIM, ensuring that multicast traffic is rapidly rerouted in the event of a failure. This document uses the backup path computed by TI-LFA through IGP as a secondary Upstream Multicast Hop (UMH) for PIM. By using the TI-LFA backup path to send PIM secondary join messages hop- by-hop, it achieves the generation of a fast reroute backup path for PIM multicast. |
| | Protocol Independent Multicast Light (PIM Light) |
| |
| | draft-ietf-pim-light-11.txt |
| | Date: |
05/12/2024 |
| | Authors: |
Hooman Bidgoli, Stig Venaas, Mankamana Mishra, Zhaohui Zhang, Mike McBride |
| | Working Group: |
Protocols for IP Multicast (pim) |
|
This document specifies Protocol Independent Multicast Light (PIM Light) and PIM Light Interface (PLI) which does not need PIM Hello message to accept PIM Join/Prune messages. PLI can signal multicast states over networks that can not support full PIM neighbor discovery, as an example BIER networks that are connecting two or more PIM domains. This document outlines the PIM Light protocol and procedures to ensure loop-free multicast traffic between two or more PIM Light routers. |
| | IANA Considerations for Internet Group Management Protocols |
| |
|
This document specifies revised IANA Considerations for the Internet Group Management Protocol and the Multicast Listener Discovery protocol. This document specifies the guidance provided to IANA to manage values associated with various fields within the protocol headers of the group management protocols. This document obsoletes RFC 3228 and unifies guidelines for IPv4 and IPv6 group management protocols. |
| | 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 "Any Source" IP Multicasting (ASM) |
| |
|
This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support Any Source Multicast (ASM) IP Multicasting or abbreviated IP Multicast. Distribution of this memo is unlimited. This document replaces [RFC1112] for anything 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 reserved range and prevent collisions by using 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. |
| | Multipath Support for IGMP/MLD Proxy |
| |
|
This document describes multipath support for Internet Group Management Protocol (IGMP)/Multicast Listener Discovery (MLD) proxy devices. The proposed extension allows IGMP/MLD proxy devices to receive multicast sessions/channels through different upstream interfaces. An upstream interface can be selected on the basis of multiple criteria, such as subscriber information, channel/session IDs, and interface priority values. A mechanism for upstream interface takeover that enables switching from an inactive to active upstream interface is also described. |
| | PIM Flooding Mechanism and Source Discovery Enhancements |
| |
|
PIM Flooding Mechanism is a generic PIM message exchange mechanism that allows multicast information to be exchanged between PIM routers hop-by-hop. One example is PIM Flooding Mechanism and Source Discovery which allows last hop routers to learn about new sources using PFM messages, without the need for initial data registers, Rendezvous Points or shared trees. This document defines a new TLV for announcing sources that allows for Sub-TLVs that can be used for providing various types of information. This document also defines methodologies that enhance forwarding efficiency in PFM-SD deployments. |