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 <[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]<mailto:[email protected]>> Date: Wednesday, June 6, 2018 at 3:14 PM To: Rob Shakir <[email protected]<mailto:[email protected]>>, Michael McBride <[email protected]<mailto:[email protected]>> Cc: Xiejingrong <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "Zafar Ali (zali)" <[email protected]<mailto:[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]<mailto:[email protected]>> on behalf of Rob Shakir <[email protected]<mailto:[email protected]>> Date: Monday, June 4, 2018 at 12:45 PM To: Michael McBride <[email protected]<mailto:[email protected]>> Cc: Xiejingrong <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[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]<mailto:[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
