Robert, I concur with Eric. I also think that the scenarios you describe as relevant for SR-fan-out/SR-spray (“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”) strongly resembles IGMP/MLD Proxy applications (RFC 4605<https://tools.ietf.org/html/rfc4605>). Is such an analogy correct?
Last but not least, it seems that your description of SR-fan-out mandates usage of domain-wide labels (mentioned by Eric as well_. If this is indeed so, I consider this as a stopper because usage of domain-wide labels has been discussed many times in the past and rejected by the MPLS WG. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: [email protected] From: [email protected] [mailto:[email protected]] On Behalf Of Robert Raszuk Sent: Thursday, June 7, 2018 7:04 PM To: Eric C Rosen <[email protected]> Cc: Alexander Vainshtein <[email protected]>; [email protected]; Xiejingrong <[email protected]>; Michael McBride <[email protected]>; Rob Shakir <[email protected]>; Zafar Ali (zali) <[email protected]>; Voyer, Daniel <[email protected]> Subject: Re: [spring] Updating the SPRING WG Charter 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]<mailto:[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. ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___________________________________________________________________________
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
