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) <jorge.raba...@nokia.com> 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 <nore...@ietf.org> > Date: Wednesday, January 15, 2025 at 8:55 AM > To: int-...@ietf.org <int-...@ietf.org> > Cc: bess@ietf.org <bess@ietf.org>, > draft-ietf-bess-evpn-redundant-mcast-source....@ietf.org < > draft-ietf-bess-evpn-redundant-mcast-source....@ietf.org>, > last-c...@ietf.org <last-c...@ietf.org> > 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 > > > >
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
