Multicast VPN Using BIER
draft-ietf-bier-mvpn-11

Note: This ballot was opened for revision 09 and is now closed.

(Alia Atlas) Yes

Deborah Brungard No Objection

Ben Campbell No Objection

Comment (2018-02-07 for -09)
No email
send info
-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) No Objection

Alissa Cooper No Objection

Spencer Dawkins No Objection

Comment (2018-02-07 for -09)
No email
send info
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 No Objection

Warren Kumari No Objection

Comment (2018-03-07 for -10)
No email
send info
Finally, an MVPN doc I can actually understand :-)

Mirja Kühlewind No Objection

Terry Manderson No Objection

(Kathleen Moriarty) No Objection

Eric Rescorla No Objection

Comment (2018-03-08 for -10)
No email
send info
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.

Alvaro Retana No Objection

Comment (2018-02-06 for -09)
No email
send info
[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

Adam Roach No Objection