Hello Joel and WG chairs. I’m in agreement with the authors/editors assertion that we have a single data plane and we can close this issue.
The document defines two new flavors of SID and applies them to existing behaviors. The resultant behaviors are implemented only on the device deploying them, and both flavors may appear in the same SRH (thanks Changwang for the illustration email). The element computing a path using the SIDs available in the network knows the behavior of the SIDs deployed and is able to build a SID list with them, IGPs and BGP-LS distribute this information for consumption (including local compute on SR source nodes). The act of compressing the SID list is documented in section 7.2 of this draft, with implementations from vendors listed in section 13. It’s worth noting that an SR source encapsulates and forwards packets as described in RFC8754 section 3.1, using the segment list that was built/compressed, regardless of the behaviors or flavor of SIDs in that segment list. That holds true for the SID flavors defined in this draft. Thanks to all involved for getting this and the other issues closed. Darren On 2023-07-31, 5:09 PM, "spring" <spring-boun...@ietf.org> wrote: As per the discussions on list and at IETF 117, the SPRING WG chairs (myself and Alvaro specifically) are attempting to determine if we can close the open issues regarding https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/ The editors have entered proposed resolutions for all open issues. This email is to determine if the working group considers issue 1 closable. Issue 1 reads: Given that the working group has said that it wants to standardize one data plane solution, and given that the document contains multiple SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will address whether this is valid and coherent with its one data plane solution objective. The editors have entered: All SIDs of the SRv6 dataplane (defined in this document and in other documents) can co-exist in the same SRH. This make SRv6 a single, consistent dataplane solution. Please speak up if you agree this resolves this issue, or if you consider that it does not resolve the issue. Objections (and even support if practical) should be specific as to the technical grounds for the statement. Silence will not be considered consent. This call will run for 3 weeks to allow time for at least some people's August vacations and in hopes fo getting a clear reading from the WG. Separate calls for other issues will be issued on a schedule that the chairs have selected to try to balance getting sufficient focus with getting this done, as it has been a long time. Note that if the WG agrees that all issues may be marked as closed, the chairs anticipate issuing the WG last call shortly after that is determined. Speaking up early will help us in all dimensions. If we determine that not all issues can be marked as closed, the chairs will work with the document editors to determine suitable next steps. Thank you, Joel
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
