Multicast VPN Using Bit Index Explicit Replication (BIER)
RFC 8556
Yes
No Objection
Note: This ballot was opened for revision 09 and is now closed.
Alvaro Retana No Objection
[I am balloting No Objection, and not DISCUSS [1], because I think this comment is very easy to address.] The reference to draft-ietf-bess-mvpn-expl-track (EXPLICIT_TRACKING) should be Normative because of the use of the LIR-pF flag in this document. [1] https://www.ietf.org/iesg/statement/discuss-criteria.html#stand-disc
Warren Kumari No Objection
Finally, an MVPN doc I can actually understand :-)
(Alia Atlas; former steering group member) Yes
(Adam Roach; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
(Ben Campbell; former steering group member) No Objection
-1, last paragraph: There are a few instances of lower case versions of 2119 keywords. Please consider using the boilerplate from RFC 8174.
(Benoît Claise; former steering group member) No Objection
(Deborah Brungard; former steering group member) No Objection
(Eric Rescorla; former steering group member) No Objection
IMPORTANT: This document really needs to minimally acknowledge in the security considerations that it is using "VPN" in 4364 sense and not in the sense that it provides actual privacy against network attackers in the Internet Threat Model. It may be hidden somewhere in the references, but I think this document ought to state it explicitly. I'm balloting No-Objection rather than DISCUSS because I think this is easily addressed and trust the ADs to handle it.
(Kathleen Moriarty; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
One of the most readable documents on MVPN that I can remember reading. Thanks for that. When reading Section 2.2, I found myself wondering why you'd choose the optional explicit tracking mechanism, but found this text This method greatly reduces the number of S-PMSI A-D routes that a BFIR needs to originate; it can now originate as few as one such route (a (C-*,C-*) S-PMSI A-D route), rather than one for each C-flow. However, the method does not provide a way for the BFIR to assign a distinct label to each C-flow. Therefore it cannot be used when segmented P-tunnels are in use (see Section 4 for an explanation). in Section 2.2.2. I wonder if it's worth moving that text to the end of Section 2.2, so the reader goes into 2.2.1 and 2.2.2 understanding the advantage of the optional mechanism?
(Suresh Krishnan; former steering group member) No Objection
(Terry Manderson; former steering group member) No Objection