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

one very simple comment:  

Section 1.1:  Add EVI, and PE.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "traditional"; alternatives might be "classic", "classical", "common",
   "conventional", "customary", "fixed", "habitual", "historic",
   "long-established", "popular", "prescribed", "regular", "rooted",
   "time-honored", "universal", "widely used", "widespread"

A run of idnits revealed probably one warning (for an IPv6 example) that might warrant attention.

draft-ietf-bess-evpn-redundant-mcast-source-14.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------

     No issues found here.

  Checking nits according to
  https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------

  == There is 1 instance of lines with non-ascii characters in the
     document.

  == The page length should not exceed 58 lines per page, but there was
     1 longer page, the longest (page 1) being 1660 lines


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------

  -- The document has examples using IPv4 documentation addresses
     according to RFC6890, but does not use any IPv6 documentation
     addresses.  Maybe there should be IPv6 examples, too?


  Miscellaneous warnings:
  ----------------------------------------------------------------------

  -- The document date (30 January 2025) is 4 days in the past.  Is
     this intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative
     references to lower-maturity documents in RFCs)

     No issues found here.

     Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments
     (--).

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 5, paragraph 1
> when forwarding G-traffic received on a S-ES. This label is allocated from a
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 5.1, paragraph 4
> ets from the redundant G-sources with a S-ESI label, regardless of the PMSI t
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Thank you to Meral Shirazipour for the GENART review.

# Éric Vyncke, INT AD, comments for draft-ietf-bess-evpn-redundant-mcast-source-14
CC @evyncke

Thank you for the work put into this document. As usual with BESS document, the text is not easy to understand by non-BESS readers, but I guess this is the nature of this WG.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Mankamana Prasad Mishra for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

Other thanks to Dirk Von Hugo, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-bess-evpn-redundant-mcast-source-13-intdir-telechat-von-hugo-2025-01-15/ (and I have read Jorge's reply)

I hope that this review helps to improve the document,

Regards,

-éric


## COMMENTS (non-blocking)

### No IETF Last Call RTG-dir review ?

Is there a reason why there were no request for an IETF Last Call review by RTG directorate (only an early review) ?

In the same vein, any reason why the mcast WGs (at least PIM) were not copied explicitly during the WG Last Call ? After all, this is mcast related.

### Section 1

Suggest adding a reference to the EVPN RFC.

s/Each receiver should receive only one of the multiple flows/Each receiver should receive only from one source/ ?

### Section 1.1

Should references be added for IGMP, MLD, BIER, ...

### Section 1.3 and other places

The figure and text only use IGMP even if MLD is also supported (I hope). Please use MLD only and indicate in the introduction that MLD stands for IGMP/MLD.

### Section 4.1

As indicated by id-nits, the examples are IPv4-only. There should be some examples (perhaps in other sections) with IPv6 as well.

### Section 5.3

Should a reference to BFD be added ?

## NITS (non-blocking / cosmetic)

Is there a reason why `Broadcast Domain` is capitalized ?

s/ethernet/Ethernet/

### Abstract

s/Layer 2 and Layer 3 services/layer-2 and layer-3 services/

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try ;-)

(Correcting ballot type) 

- Thanks for the invaluable worked examples. 

- It appears [I-D.ietf-mpls-p2mp-bfd] needs to be a normative reference, since it’s not just exemplary.