Skip to main content

Multicast Source Redundancy in EVPN Networks
draft-ietf-bess-evpn-redundant-mcast-source-15

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, bess-chairs@ietf.org, bess@ietf.org, draft-ietf-bess-evpn-redundant-mcast-source@ietf.org, gunter@vandevelde.cc, mankamis@cisco.com, rfc-editor@rfc-editor.org
Subject: Protocol Action: 'Multicast Source Redundancy in EVPN Networks' to Proposed Standard (draft-ietf-bess-evpn-redundant-mcast-source-13.txt)

The IESG has approved the following document:
- 'Multicast Source Redundancy in EVPN Networks'
  (draft-ietf-bess-evpn-redundant-mcast-source-13.txt) as Proposed Standard

This document is the product of the BGP Enabled ServiceS Working Group.

The IESG contact persons are Gunter Van de Velde, Jim Guichard and John
Scudder.

A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-redundant-mcast-source/


Ballot Text

Technical Summary

   In Ethernet Virtual Private Networks (EVPNs), IP multicast traffic
   replication and delivery play a crucial role in enabling efficient
   and scalable Layer 2 and Layer 3 services.  A common deployment
   scenario involves redundant multicast sources that ensure high
   availability and resiliency.  However, the presence of redundant
   sources can lead to duplicate IP multicast traffic in the network,
   causing inefficiencies and increased overhead.  This document
   specifies extensions to the EVPN multicast procedures that allow for
   the suppression of duplicate IP multicast traffic from redundant
   sources.  The proposed mechanisms enhance EVPN's capability to
   deliver multicast traffic efficiently while maintaining high
   availability.  These extensions are applicable to various EVPN
   deployment scenarios and provide guidelines to ensure consistent and
   predictable behavior across diverse network topologies.

Working Group Summary

   Was there anything in the WG process that is worth noting?
   For example, was there controversy about particular points 
   or were there decisions where the consensus was
   particularly rough? 

This work had broad WG agreement and had good support across multiple vendors

Document Quality

   Are there existing implementations of the protocol?  Have a 
   significant number of vendors indicated their plan to
   implement the specification?  Are there any reviewers that
   merit special mention as having done a thorough review,
   e.g., one that resulted in important changes or a
   conclusion that the document had no substantive issues?  If
   there was a MIB Doctor, Media Type, or other Expert Review,
   what was its course (briefly)?  In the case of a Media Type
   Review, on what date was the request posted?

This work has intersection with multicast. however all the procedure are limited to scope of BESS working group.

Personnel

   The Document Shepherd for this document is Mankamana Prasad Mishra. The
   Responsible Area Director is Gunter Van de Velde.

IANA Note

  IANA OK

RFC Editor Note