Ballot for draft-ietf-bier-mvpn
Yes
No Objection
Note: This ballot was opened for revision 09 and is now closed.
Finally, an MVPN doc I can actually understand :-)
[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
-1, last paragraph: There are a few instances of lower case versions of 2119 keywords. Please consider using the boilerplate from RFC 8174.
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.
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?