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

[Dirk Hugo <[e-mail]>]

Hi Jorge, thanks for the reply and fine for me! Sorry for late reaction,
your mail was overseen. All the best
Dirk

On Thu, Jan 30, 2025, 7:29 PM Jorge Rabadan (Nokia) <[e-mail]>
wrote:

> 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
>
>
>
>