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> 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. > > > 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? > > > 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> 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> 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> > *Date: *Wednesday, August 9, 2023 at 5:43 AM > *To: *Zafar Ali (zali) <z...@cisco.com> > *Cc: *Joel Halpern <j...@joelhalpern.com>, SPRING WG List <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> <spring-boun...@ietf.org> on > behalf of Joel Halpern <j...@joelhalpern.com> <j...@joelhalpern.com> > *Date: *Monday, July 31, 2023 at 5:09 PM > *To: *SPRING WG List <spring@ietf.org> <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 > > https://www.ietf.org/mailman/listinfo/spring > > > > _______________________________________________ > 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
