Hi Darren, I agree that in the current form, the authors asserted that proposed C-SID mechanisms are parts of the single data plane. But, as I've noted earlier, that the resolution should come as a conclusion, not an assertion. I hope that the authors will share text that would illustrate in detail, pointing out to all exclusions and restrictions, interworking of the two C-SID approaches encoded in the same SRH instance. I believe that without such demonstration, without converting from an assertive form to documenting the interaction of SID compressions in the same SRH the issue cannot be closed, cannot be marked as addressed.
Regards, Greg On Mon, Aug 14, 2023 at 7:23 AM Darren Dukes (ddukes) <ddukes= 40cisco....@dmarc.ietf.org> wrote: > 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 >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
