Hi, Joel, Authors, et al., I have a clarification question and appreciate your help answering it. According to RFC 8986:
SRv6 Endpoint behavior: A packet processing behavior executed at an SRv6 Segment Endpoint Node. As I understand it, two compression techniques, NEXT-C-SID and REPLACE-C-SID, are defined in draft-ietf-spring-srv6-srh-compression. While reading the proposed resolution, it seems like the authors suggest that SIDs compressed using both techniques, i.e., NEXT-C-SID and REPLACE-C-SID, can arbitrarily appear in the same instance of SRH. Is my interpretation of the proposed resolution correct? Personally, I have doubts that such a mix of compression techniques is possible and would appreciate it if the authors extended the resolution with an example that clearly demonstrates how NEXT-C-SID and REPLACE-C-SID can both be used to compress SIDs that populate the same SRH. And there seems to be a nit in the proposed resolution text that can be fixed by s/make/makes/. Regards, Greg On Mon, Jul 31, 2023 at 2:08 PM Joel Halpern <j...@joelhalpern.com> 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 >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
