Eric, > I have a number of comments on the virtual-hub draft. Some are minor and/or > editorial, but a number are more substantial. I think these comments need > to be addressed before the draft is submitted for publication. > > I've placed a lot of comments in-line, but let me summarize what I think are > the major issues:
I am in the process of addressing your comments. In this e-mail I'd 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? Please note that the procedures specified in the draft assume the ability to perform sender-based RPF, as specified in 9.1.1 of rfc6513. Given that, if one would follow what you outlined above, could you point me to the specific text in 9.1.1 that would enable V-spoke1 to determine that from its own perspective the UMH for (C-S, C-G) is V-hub1 ? Furthermore, your outline above talks about S-PMSI A-D route. How would it work for I-PMSI A-D routes ? Yakov.
