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.
On more question, in addition to the questions I raised in the e-mail I sent you earlier today: How would your alternative support scenarios where the root of a P-tunnel needs to know leaves of that tunnel (e.g., p2mp RSVP-TE is used for P-tunnel, or the root performs aggregation using upstream-assigned label)? E.g., using your example above, assume that V-hub2 originated an (C-S, C-G) S-PMSI A-D route with Leaf Information Required. Please point me to the procedures in rfc6513, rfc6514 that would result in a Leaf A-D route originated by V-spoke1 to be received (and correctly processed) by V-hub2. Yakov.
