Yakov> I am in the process of addressing your comments. In this e-mail I'd Yakov> like to focus on one particular one:
Eric> Let's consider the case where the source is at a site attached to Eric> V-hub2. V-hub1 will receive an S-PMSI A-D route matching (S,G) from Eric> V-hub2. V-hub1 then modifies this A-D route and forwards it to Eric> V-spoke1. V-hub1 could use this route to identify the P-tunnel Eric> originating at V-hub2, thereby instructing V-spoke1 to join V-hub2's Eric> tunnel directly. Then V-hub1 would not be in the data path from S to Eric> R, but it would participate in the control plane. Wouldn't this meet Eric> all the requirements of the V-hub/V-spoke architecture, while producing Eric> a more optimal path for multicast data, and eliminating the need to Eric> have the V-hubs splice together any P-tunnels? Eric> Was any consideration given to such an alternative? Yakov> Please note that the procedures specified in the draft assume Yakov> the ability to perform sender-based RPF, as specified in 9.1.1 Yakov> of rfc6513. The text of RFC6513 does not anticipate the use of a "virtual hub". But what's wrong with the following procedure: - V-spoke1 selects V-hub1 as the upstream PE for (C-S,C-G). - V-hub1 instructs V-spoke1 to receive (C-S,C-G) traffic from a unidirectional P-tunnel rooted at V-hub2. (V-spoke1 follows this instruction because V-hub1 is its upstream PE for (C-S,C-G).) - V-spoke1 drops any (C-S,C-G) traffic that did not arrive from V-hub2 over the specified P-tunnel. Yakov> Furthermore, your outline above talks about S-PMSI A-D route. How Yakov> would it work for I-PMSI A-D routes ? Since V-spoke1 cannot determine the real upstream PE, V-spoke1 would probably have to get a (C-S,C-G) S-PMSI A-D route from V-hub1 for each (C-S,C-G) in which V-spoke1 has interest. The PMSI Tunnel attribute would identify the real upstream PE. I think V-hub1 has the necessary state to generate these, since it gets the C-multicast Joins its associated spokes. Of course, there are trade-offs to be considered.
