Skip to main content

Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures
draft-ietf-bess-mvpn-global-table-mcast-03

Yes

(Alvaro Retana)

No Objection

(Alissa Cooper)
(Barry Leiba)
(Ben Campbell)
(Deborah Brungard)
(Joel Jaeggli)
(Spencer Dawkins)

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

Alvaro Retana Former IESG member
Yes
Yes (for -02) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -02) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (for -02) Unknown

                            
Ben Campbell Former IESG member
No Objection
No Objection (for -02) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (2015-09-01 for -02) Unknown
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?
Deborah Brungard Former IESG member
No Objection
No Objection (for -02) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -02) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2015-09-02 for -02) Unknown
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
Spencer Dawkins Former IESG member
No Objection
No Objection (for -02) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2015-09-02 for -02) Unknown
What Kathleen said.