Re: [spring] Updating the SPRING WG Charter

[Robert Raszuk <[e-mail]>]

Hi Sasha,

I think there is technology to allow that.

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.

Some folks call it SR-spray, I call it SR-fanout - but it does seems very
useful so I support keeping it in the proposed charter.

Many thx,
Robert,




On Thu, Jun 7, 2018 at 4:47 PM, Alexander Vainshtein <
[e-mail]> wrote:

> Hi all,
>
> I do not think that SPRING WG should deal with MC – possibly, excluding
> use of ingress replication for multicast.
>
>
>
> This is based on what I see as the key element (highlighted) in
> definition of SPRING activities in the proposed charter:
>
>
>
> The SPRING WG defines procedures that allow a node to steer a packet
> through an
>
> SR Policy instantiated as an ordered list of instructions called segments
> and
>
> without the need for per-path state information to be held at transit nodes
> .
>
>
>
> To the best of my understanding, the only way for SR to provide this
> functionality forf multicast (be it SR-MPLS or SRV6) is ingress replication
> using unicast SR paths. In particular, the framework defined in
> draft-allan
> <https://tools.ietf.org/html/draft-allan-spring-mpls-multicast-framework-03>
> explicitly requires per-path state in the replication points.
>
>
>
> From my POV the only technology that allows MC traffic to traverse the
> transit nodes without per-path state in the transit nodes and without
> multiple copies of the packet crossing the same link is BIER.
>
>
>
> My 2c,
>
> Sasha
>
>
>
> Office: [phone]
>
> Cell:      [phone]
>
> Email:   [e-mail]
>
>
>
> *From:* spring [mailto:[e-mail]] *On Behalf Of *Voyer,
> Daniel
> *Sent:* Wednesday, June 6, 2018 11:20 PM
> *To:* Zafar Ali (zali) <[e-mail]>; Rob Shakir <robjs=
> [e-mail]>; Michael McBride <[e-mail]>
> *Cc:* Xiejingrong <[e-mail]>; [e-mail]
>
> *Subject:* Re: [spring] Updating the SPRING WG Charter
>
>
>
> Hi all,
>
>
>
> I support and agree w/ Zafar.
>
>
>
> Multicast in SR is much needed and there is lots of development that needs
> to happen, whether for SRv6 or with SR-MPLS. The core architecture and
> development need to be included in this working group.
>
>
>
> Thanks,
>
> dan
>
>
>
>
>
> *From: *"Zafar Ali (zali)" <[e-mail]>
> *Date: *Wednesday, June 6, 2018 at 3:14 PM
> *To: *Rob Shakir <robjs=[e-mail]>, Michael McBride <
> [e-mail]>
> *Cc: *Xiejingrong <[e-mail]>, "[e-mail]" <
> [e-mail]>, "Zafar Ali (zali)" <[e-mail]>
> *Subject: *Re: [spring] Updating the SPRING WG Charter
>
>
>
> Hi Rob,
>
>
>
> The multicast in SR belongs to the same category as I highlighted in my
> last email. Just to repeat …
>
>
>
> At IETF101, you and Bruno presented a slide based on the WG feedback on
> the mailing list (https://datatracker.ietf.org/
> meeting/101/materials/slides-101-spring-00-chairs-slides-01). During the
> Spring meeting, the WG agreed to add milestones to those items. In general,
> I see some milestones are not included in the proposed chartered text.
>
>
>
> Specifically, multicast in SR is included in that list with the "Ingress
> replication SID (Tree SID /spray)" bullet (and support during the WG
> meeting) but is missing in the proposed charter text. So, I agree with
> Xiejingrong and Michael highlighting the same. There is already interest
> and agreement shown by the WG to include multicast in SR in the charter.
>
>
>
> In the light of the above, please add a milestone for the WG to specify
> architecture, and the required protocol extensions for multicast in SR with
> MPLS and IPv6 data planes, including specification of the ingress
> replication SIDs (e.g., Tree SID, Spray). Nonetheless, I wholeheartedly
> agree that the actual protocol extension work should be done at the WG that
> owns the protocol.
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
> *From: *spring <[e-mail]> on behalf of Rob Shakir <
> robjs=[e-mail]>
> *Date: *Monday, June 4, 2018 at 12:45 PM
> *To: *Michael McBride <[e-mail]>
> *Cc: *Xiejingrong <[e-mail]>, "[e-mail]" <
> [e-mail]>
> *Subject: *Re: [spring] Updating the SPRING WG Charter
>
>
>
> Michael,
>
>
>
> Thanks for the comment.
>
> On Mon, Jun 4, 2018 at 9:42 AM Michael McBride <[e-mail]>
> wrote:
>
> It would be helpful, while updating the charter, to state whether
> multicast in SR is in/out of scope in order to know which wg to take our
> future work.
>
>
>
> I think this is impractical. If we state everything that is in or out of
> scope, we'll end up with a laundry list. The aim of the charter is to
> define clearly the work that the WG should focus on. It does not mean that
> we can never host discussion of individual drafts if they are relevant. If
> there are requirements, we can always recharter if something new becomes
> the highest priority for the industry w.r.t SR.
>
>
>
> Kind regards,
>
> r.
>
> ____________________________________________________________
> _______________
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>
>