Multicast Source Redundancy in EVPN Networks
draft-ietf-bess-evpn-redundant-mcast-source-09
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
Expired & archived
|
|
|---|---|---|---|
| Authors | Jorge Rabadan , Jayant Kotalwar , Senthil Sathappan , Zhaohui (Jeffrey) Zhang , Wen Lin | ||
| Last updated | 2024-07-25 (Latest revision 2024-01-22) | ||
| Replaces | draft-skr-bess-evpn-redundant-mcast-source | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
INTDIR Telechat review
(of
-13)
by Dirk Von Hugo
Ready w/nits
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Consensus: Waiting for Write-Up | |
| Document shepherd | Mankamana Prasad Mishra | ||
| Shepherd write-up | Show Last changed 2024-07-17 | ||
| IESG | IESG state | Expired | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | mankamis@cisco.com |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
Ethernet Virtual Private Network (EVPN) supports intra and inter- subnet IP multicast forwarding. However, EVPN (or conventional IP multicast techniques for that matter) do not have a solution for the case where the following two statements are true at the same time: a) a given multicast group carries more than one flow (i.e., more than one source), and b) it is desired that each receiver gets only one of the several flows. Existing multicast techniques assume there are no redundant sources sending the same flow to the same IP multicast group, and, in case there were redundant sources, the receiver's application would deal with the received duplicated packets. This document extends the existing EVPN specifications and assumes that IP Multicast source redundancy may exist. It also assumes that, in case two or more sources send the same IP Multicast flows into the tenant domain, the EVPN PEs need to avoid that the receivers get packet duplication by following the described procedures.
Authors
Jorge Rabadan
Jayant Kotalwar
Senthil Sathappan
Zhaohui (Jeffrey) Zhang
Wen Lin
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)