[Last-Call] Intdir telechat review of draft-ietf-bess-evpn-redundant-mcast-source-13

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux