Ballot for draft-ietf-pim-drlb
Yes
No Objection
Note: This ballot was opened for revision 13 and is now closed.
I support Ben Kaduk's DISCUSS position.
Thank you for this document -- I found it easy to read and helpful. I'd note that the document has 6 authors instead of the "recommended" 5 -- I don't care, just noting it. Also, please see the OpsDir review ( https://datatracker.ietf.org/doc/review-ietf-pim-drlb-13-opsdir-lc-clarke-2019-10-30/ ) for some useful editorial fixes.
Thank you for the work put into this document. The short document is easy to read. I have one COMMENT and one NIT below, feel free to ignore them. Regards, -éric == COMMENT == -- Section 5.1 -- Some more explanations about "These default values are likely acceptable" would be welcome. == NIT == -- Section 1 -- s/ on behalf of any local members/on behalf of all local members/ ?
Please consider formatting IPv6 address as per the recommendations in RFC 5952, and section 4.3 of that document (https://tools.ietf.org/html/rfc5952#section-4.3) in particular.
Some very minor comments: Please expand “PIM-SM” on first use in both the Abstract and the Introduction. This allows the forwarding of multicast packets to be restricted only to segments leading to receivers who have indicated their interest in multicast groups using either IGMP or MLD. Nit: Let’s not personify our devices: please change “who” to “that”. However, if there was a way that allowed multiple routers to forward to the LAN for different groups, failure of one of the Nit: “if there were a way”, subjunctive mood with a conditional. — Section 3 — The extension specified in this document applies to PIM-SM when they act as last hop routers (there are directly connected receivers). I can’t find the antecedent to “they”; what is it? It looks like it’s “PIM-SM”, but that’s not something that can be “they”, is it? Maybe you mean to say “PIM-SM routers”? — Section 4 — For each multicast flow, that is, (*,G) for ASM and (S,G) for SSM, a Hash Algorithm is used to select one of the routers to be the GDR. “Hash Algorithm” might do well to include a forward reference to Section 5.1.
Thank you for the updates that address my original Discuss points! At the time of this writing, we're still having a little more discussion in email about some of the specifics of the 32-bit masking procedure, but it seems unlikely to cause problems in practice, and the algorithm selection allows for a fix to be made in the future without needing changes at present (provided that the procedure to apply the mask is clearly specified).
Please have a look at the TSV-ART review, there is an editorial suggestion that might be worth considering (and thanks Michael for the TSV-ART review!).