Re: [spring] Updating the SPRING WG Charter

[Alexander Vainshtein <[e-mail]>]

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: [phone]
Cell:      [phone]
Email:   [e-mail]

From: [e-mail] [mailto:[e-mail]] On Behalf Of Robert Raszuk
Sent: Thursday, June 7, 2018 7:04 PM
To: Eric C Rosen <[e-mail]>
Cc: Alexander Vainshtein <[e-mail]>; [e-mail]; Xiejingrong <[e-mail]>; Michael McBride <[e-mail]>; Rob Shakir <robjs=[e-mail]>; Zafar Ali (zali) <[e-mail]>; Voyer, Daniel <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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.
___________________________________________________________________________