Hi Greg, thanks for giving this more thought! Please see inline [DD] On 2023-08-22, 6:55 PM, "Greg Mirsky" <gregimir...@gmail.com> wrote:
Hi Darren, thank you for your thoughtful consideration of my suggestion. I put several notes in-line under the GIM>> tag. Regards, Greg On Wed, Aug 16, 2023 at 10:12 AM Darren Dukes (ddukes) <ddu...@cisco.com<mailto:ddu...@cisco.com>> wrote: Hi Greg, thanks for clarifying your concerns with proposed text. I like the inclusion of “and/or”, it makes it clear to the reader immediately that a segment list consisting of both flavors is compressible by the following processes. I would not include “in a single SRH” since the presence of the SRH is not guaranteed (see the last part of section 7.2 where RFC8754 text is reproduced to describe the SR source encapsulation.) GIM>> As I understand it, combining NEXT-C-SID and REPLACE-C-SID is not permitted in a single C-SID container. If that is the case, then an SRH must be used and the reference to it seems justified to me. [DD] Yes, there are cases when an SRH is present but there are cases where there is no SRH present (compression resulting in a single C-SID container. Given it may or may not be present, I think the more correct text is to either omit “in a single SRH” or be more precise and say “in one or more C-SID containers” and let the remainder of the section provide the details. What do you think? It’s worth noting that the second paragraph of 7.2 includes the “and” statement: “This method walks the uncompressed segment list and compresses each series of consecutive eligible NEXT-C-SID flavored SIDs and each series of consecutive eligible REPLACE-C-SID flavored SIDs” GIM>> Thank you for bringing this statement to my attention. I believe that it stresses that consecutive sequences of C-SIDs of different flavors must be eligible for the combined compression. Is my understanding of the eligibility clause correct? What happens if a C-SID doesn't conform to one of the eligibility conditions listed in Section 7.2? [DD] The remainder of 7.2 tells us the non-eligible SIDs would not be included in the series of SIDs to compress and therefore not be compressed. Thanks Darren The subsequent text describes how to compress each series without assumption of how many times one may appear. “When the compression method encounters a series of consecutive eligible NEXT-C-SID or REPLACE-C-SID flavored SIDs, it compresses the series as follows.” Would you agree that adding “and/or” to the first paragraph is all that’s needed here? Thanks Darren On 2023-08-16, 11:54 AM, "spring" <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> wrote: Hi Zafar, thank you for pointing out the text in Section 7.2. I think that it might be the right place to illustrate that the defined behaviors indeed are part of the same data plane. And it can be started with an update of the first sentence like the following: OLD TEXT: An SR source node MAY compress a segment list when it includes NEXT- C-SID or REPLACE-C-SID flavor SIDs. NEW TEXT: An SR source node MAY compress a segment list when it includes NEXT- C-SID and/or REPLACE-C-SID flavor SIDs in a single SRH.t As I understand it, Section 7.2 describes the "or" case. Adding the description of procedures for the "and" case would help change the proposed assertion into a conclusion. Regards, Greg On Wed, Aug 16, 2023 at 8:01 AM Zafar Ali (zali) <zali=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>> wrote: Hi Nick, Thanks for your email - sorry for delayed response as I am out-of-office. Yes, and the section 7.2 explains how to compress SID list using the next flavor or the replace flavor or both. Emails from Changwang Lin and Darren Dukes on this tread provides further explanation. I hope that clarifies your query. Thanks Regards … Zafar From: Nick Hilliard <n...@foobar.org<mailto:n...@foobar.org>> Date: Wednesday, August 9, 2023 at 5:43 AM To: Zafar Ali (zali) <z...@cisco.com<mailto:z...@cisco.com>> Cc: Joel Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>>, SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>> Subject: Re: [spring] Issue 1 regarding draft-ietf-spring-srv6-srh-compression Zafar, can you confirm that if Router A in one domain uses next-c-sid and Router B in another domain uses replace-c-sid, that they will be able to interoperate? I'm not picking this up from the draft, and this would be the overriding operational consideration in terms of what a single data plane solution ought to look like in the wild. Nick Zafar Ali (zali) wrote on 08/08/2023 06:48: Dear WG chairs and the WG, I agree that this resolves the issue 1; it is a single data plane solution compliant with the specifications in [RFC8402], [RFC8754] and [RFC8986], aka SRv6 data plane. Thanks Regards … Zafar From: spring <spring-boun...@ietf.org><mailto:spring-boun...@ietf.org> on behalf of Joel Halpern <j...@joelhalpern.com><mailto:j...@joelhalpern.com> Date: Monday, July 31, 2023 at 5:09 PM To: SPRING WG List <spring@ietf.org><mailto:spring@ietf.org> Subject: [spring] Issue 1 regarding draft-ietf-spring-srv6-srh-compression 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<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
