[bess] Re: Éric Vyncke's No Objection on draft-ietf-bess-evpn-redundant-mcast-source-14: (with COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Hello Jorge,

Thank you for your quick and detailed reply (as usual ;-) ).

Still wondering about the absence of cross-posting the WGLC to the PIM WG, but there was anyway an IETF Last Call that included PIM participants obviously.

Ack for the rest of your answers.

Regards

-éric

From: Jorge Rabadan (Nokia) <[e-mail]>
Date: Friday, 14 February 2025 at 20:13
To: Eric Vyncke (evyncke) <[e-mail]>, The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Mankamana Mishra (mankamis) <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-bess-evpn-redundant-mcast-source-14: (with COMMENT)
Hi Éric,

As usual thanks very much for yet another high quality review.
We addressed your comments in version 15, just published.

Please, see some comments in-line below with [jorge].

Thanks!
Jorge

From: Éric Vyncke via Datatracker <[e-mail]>
Date: Wednesday, February 5, 2025 at 1:41 PM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Éric Vyncke's No Objection on draft-ietf-bess-evpn-redundant-mcast-source-14: (with COMMENT)

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.



Éric Vyncke has entered the following ballot position for
draft-ietf-bess-evpn-redundant-mcast-source-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-redundant-mcast-source/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


# É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.
[jorge] I don’t have an answer for the first question. About the second one, this document builds on procedures established in the BESS WG, including multicast-related procedures outlined in RFC 9251 and RFC 9625. Since these foundational mechanisms are already defined in BESS, involving the PIM WG was not strictly necessary. It is also important to highlight that some people that reviewed the document and even some authors are active participants in PIM WG.



### Section 1

Suggest adding a reference to the EVPN RFC.
[jorge] added.


s/Each receiver should receive only one of the multiple flows/Each receiver
should receive only from one source/ ?
[jorge] modified


### Section 1.1

Should references be added for IGMP, MLD, BIER, ...
[jorge] added.


### 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.
[jorge] we added IGMP/MLD in all the examples.


### 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.
[jorge] added ipv6 examples too, as also requested by Mahesh


### Section 5.3

Should a reference to BFD be added ?
[jorge] there was a discussion within the WG about what references to use for BFD. In the end the agreement was to use the one in the document.


## NITS (non-blocking / cosmetic)

Is there a reason why `Broadcast Domain` is capitalized ?
[jorge] it has a specific meaning in the EVPN procedures, I think it is ok..?


s/ethernet/Ethernet/
[jorge] fixed


### Abstract

s/Layer 2 and Layer 3 services/layer-2 and layer-3 services/
[jorge] fixed


### 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 ;-)
[jorge] hmm.. I didn’t know SVGs could be used! I’ll look into it, even if it is not for this document since it is pretty much done already… thanks for the pointer!