Re: [spring] Updating the SPRING WG Charter

[Robert Raszuk <[e-mail]>]

Sasha,

> because usage of domain-wide labels has been discussed many times in the
past and rejected by the MPLS WG.

That comment I quite do not follow. Entire concept of SR-MPLS  is based on
domain wide labels (distributed via IGP or OOB) and my description applies
to SR based networks with both MPLS as well as v6 encap.

In other words we already have domain wide MPLS labels to indicate various
types of segments. What I proposed would at most require perhaps new type
which would embed node + replication function.

Thx,
R.


On Fri, Jun 8, 2018 at 4:53 PM, Alexander Vainshtein <
[e-mail]> wrote:

> 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]> 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.
> ____________________________________________________________
> _______________
>