Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures
RFC 7716

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

Alvaro Retana Yes

Deborah Brungard No Objection

(Ben Campbell) No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2015-09-02 for -02)
No email
send info
What Kathleen said.

(Brian Haberman) No Objection

Comment (2015-09-01 for -02)
No email
send info
I support the publication of this document, but I have one (non-blocking) comment... I do not see any forwarding plane discussions in this document and I wonder if there was discussion about impacts on multicast forwarding.  With the removal of the VPN-related checks, is there a possibility of loops in the forwarding of multicast data based on the GTM information?  What about implications for RPF checks?

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Kathleen Moriarty) No Objection

Comment (2015-09-02 for -02)
No email
send info
Thank you for addressing the SecDir review questions.  I found the explanation helpful and think some text in the draft would be good for this particular question from the review since this is specific to this draft:

[Cathy] What is not clear here is what is additional risk of information leaking out into the wild the use of the GTM procedures proposed in this document would incur. Does the use in a wider context mean that the information is more widely distributed and thus has more chance of leaking?

[Eric/Editor response] When L3VPN/MVPN is provisioned, each VRF is configured with import RTs and export RTs. These RTs constrain the distribution and the import of L3VPN/MVPN routes, making it difficult to cause a route to be distributed to and imported by a VRF (or a global table) that is not authorized to import that route. Additionally, VPN routes do not go into the "global table" with the "ordinary Internet routes" (i.e., non-VPN routes), and non-VPN routes do not impact the flow of multicast data within a VPN.

In GTM, some of these protections against improper distribution/import of the routes is lost. Import of the routes is not restricted to VRFs, and the RT infrastructure that controls the distribution of routes among the VRFs is not present when routes are exported from and imported into global tables. But I don't think this needs to be explained in detail to the intended audience of the draft, who will already be familiar with VPN and MVPN technology.

SecDir Review:
https://www.ietf.org/mail-archive/web/secdir/current/msg05940.html