Re: [spring] Issue 1 regarding draft-ietf-spring-srv6-srh-compression

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.com@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 <nick@foobar.org>
> *Date: *Wednesday, August 9, 2023 at 5:43 AM
> *To: *Zafar Ali (zali) <zali@cisco.com>
> *Cc: *Joel Halpern <jmh@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-bounces@ietf.org> <spring-bounces@ietf.org> on
> behalf of Joel Halpern <jmh@joelhalpern.com> <jmh@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
>