Eric, > 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.
You just confirmed my point that the existing procedures in 6513 are insufficient to support your alternative, and the draft is very explicit in terms of its reliance on the 6513 procedures. > 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. For one thing, this would rule out the use of I-PMSI between V-hub and associated with it V-spokes, and would result in proliferation of (C-S, C-G) S-PMSI routes. Moreover, how would your alternative support DM (unsoliciated flooded data) ? How it would support (C-*, C-*) wildcard S-PMSI ? Yakov.
