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 < [email protected]> 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: +972-39266302 > > Cell: +972-549266302 > > Email: [email protected] > > > > *From:* spring [mailto:[email protected]] *On Behalf Of *Voyer, > Daniel > *Sent:* Wednesday, June 6, 2018 11:20 PM > *To:* Zafar Ali (zali) <[email protected]>; Rob Shakir <robjs= > [email protected]>; Michael McBride <[email protected]> > *Cc:* Xiejingrong <[email protected]>; [email protected] > > *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)" <[email protected]> > *Date: *Wednesday, June 6, 2018 at 3:14 PM > *To: *Rob Shakir <[email protected]>, Michael McBride < > [email protected]> > *Cc: *Xiejingrong <[email protected]>, "[email protected]" < > [email protected]>, "Zafar Ali (zali)" <[email protected]> > *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 <[email protected]> on behalf of Rob Shakir < > [email protected]> > *Date: *Monday, June 4, 2018 at 12:45 PM > *To: *Michael McBride <[email protected]> > *Cc: *Xiejingrong <[email protected]>, "[email protected]" < > [email protected]> > *Subject: *Re: [spring] Updating the SPRING WG Charter > > > > Michael, > > > > Thanks for the comment. > > On Mon, Jun 4, 2018 at 9:42 AM Michael McBride <[email protected]> > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/spring > >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
