Inline [DV] 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. This list was a recap of what had been discussed on the mailing list. It was not the proposed exhaustive list. [DV] I thought this was a list proposed by the working group as a response to AD’s request ? Didn’t we debate this list in our last wg meeting ?! The preference in the charter text (after much discussion) is to ensure that SPRING has a set of focus areas to work on. This does not preclude interested individuals doing other work - and even bringing it to SPRING. We can change the charter in the future if new work comes up that isn't within the charter. I would point out that the narrow scope that we (the SPRING WG) initially had to deliver on has taken almost five years since we initially discussed it (see this thread<https://www.ietf.org/mail-archive/web/status/current/msg00242.html> regarding chartering STATUS as it was at the time). In this period of time, real deployments of SR have happened, and the standards that they rely on have not yet been published.. [DV] hence my point of pushing for P2MP like trees (ingress replication SID) in SR-MPLS/SRv6 network. This is a critical requirement for Bell Canada, at least .. [DV] Also, noticed that the work is already going on in the working group, as it is part of the SR policy architecture-draft – section 9.2 – which is an now a working group document. This is unfortunate for those that have shipping implementations, or are relying on behaviours in their network. [DV] yep, unfortunate, indeed. We don’t want to repeat the same mistake for ingress replication SID, don’t we ? [..sniff] Thanks, r.
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
