Hi Eric, The way I look at this is really not from the perspective of true dynamic multicast with tree building etc .. .I look at this as anchor points to replicate unicast flows into two or more endpoints maybe once or twice in entire domain.
So for sure if you would try to apply this technique to distribute traditional multicast there is tons of things which can go wrong and you are better off with BIER. But there are applications which on one side do not really require full multicast yet they would benefit with content to be send once from server and arrived at two or more caches. Maybe we just don't have the right name for it in networking yet :) Cheers, R. On Thu, Jun 7, 2018 at 5:52 PM, Eric C Rosen <[email protected]> wrote: > On 6/7/2018 10:55 AM, Robert Raszuk wrote: > > Imagine a segment with embedded meaning that packets received with such > value X should be replicated to interfaces Y & Z. Such decision can be > configured from controller or locally computed. > > Nothing there is per-path as well as nothing there is per flow or per > multicast group. It is a local function. > > > How can you say "nothing there per-path"? The label X represents a > multicast tree, and thus constitutes per-path state. If some packets > need to go to Y and Z, some need to go to Y, Z, and W, some need to go to > Y, U, and V, etc., you obviously need a different label for each different > multicast tree, and appropriate per-tree state. > > Using a controller to set up multicast paths may be a good idea in some > scenarios, but let's not pretend it doesn't create per-path state in the > router. Per-path (per-tree) is not the same as per-flow or per-group, of > course, but that's true of any technique that aggregates flows into > multicast tunnels. > > Note also that if the label X is domain-wide unique and there is no RPF > check, there is the possibility of nasty multicast loops. These is some > discussion of this in draft-zzhang-bess-bgp-multicast-controller-00. > > > >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
