[Int-dir] Re: Intdir telechat review of draft-ietf-bess-evpn-redundant-mcast-source-13

["Jorge Rabadan (Nokia)" <[e-mail]>]

Hi Dirk,

We took all your suggestions in version 14. The only exception was the one in page 30 since it changed the meaning.
Thank you very much for your review!
Jorge (on behalf of the authors)


From: Dirk Von Hugo via Datatracker <[e-mail]>
Date: Wednesday, January 15, 2025 at 8:55 AM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Intdir telechat review of draft-ietf-bess-evpn-redundant-mcast-source-13


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.



Reviewer: Dirk Von Hugo
Review result: Ready with Nits

Dear all,
I am an assigned INT directorate reviewer for
draft-ietf-bess-evpn-redundant-mcast-source. These comments were written
primarily for the benefit of the Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat comments
from any other IETF contributors and resolve them along with any other (Last
Call) comments that have been received. For more details on the INT
Directorate, see https://datatracker.ietf.org/group/intdir/about/

The draft specifies two procedures to address high multicast availability and
resiliency together with better efficiency in terms of hot and warm standby
support in case of failure. From my non-expert point of view it is well
written, I only miss some acronym explanations and similarily found very minor
nits as described below:

P.4:
procedures for EVPN PEs to ensure => procedures for EVPN PEs (Provider Edge
devices/routers) to ensure BUM: Broadcast, Unknown unicast and Multicast
traffic => BUM: Broadcast, Unknown unicast, and Multicast traffic

P.7:
[RFC9625], [RFC9136] and [RFC9572] => [RFC9625], [RFC9136], and [RFC9572]

P.8:
such as e.g., PE4 => such as, e.g., PE4

P.12:
via the IRB interface, following => via the IRB (Integrated Routing and
Bridging) interface, defined in [RFC9135], following

P.15:
Flow Group information in the NLRI => Flow Group information in the NLRI (BGP
EVPN Network Layer Reachability Information, see [RFC9135])

P.23:
SFG configuration (and not based the reception of traffic) => SFG configuration
(and not based on the reception of traffic)

P.26:
label space identified by the Domain-wide Common Block label => label space
identified by the Domain-wide Common Block (DCB) label

P.30:
G-source with e.g., lowest ESI  => G-source with, e.g., lowest ESI
filtering follow, as specified in => filtering follow mechanisms/procedures, as
specified in

Thanks - especially to all authors and contributors!
Best regards
Dirk