Re: [spring] Conclusion from WG poll on dataplane solution for compressing segment routing over IPv6

Hi Joel et al.
in evaluating a draft during a WG AP I am looking for three questions:

   - Is the document written reasonably well to clearly convey the problem
   and proposed solution?
   - Does the problem statement reflect a real existing challenge, an issue
   that needs to be solved?
   - Is the proposed solution technically viable?

Reading the CSID draft (draft-filsfilscheng-spring-srv6-srh-compression
<https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/>)
I could positively answer the first two questions. While deciding on the
third question, I've got sense that the document describes two different
behaviors in the data plane, two ways to encode variable-length SIDs in the
SRH extension header. I agree that it can be resolved through either the
authors selecting one solution, or the WG working on that. Personally, I
encourage the authors to do that.

Regards,
Greg

On Mon, Sep 6, 2021 at 10:27 AM Joel M. Halpern <jmh@joelhalpern.com> wrote:

> Our thanks to the working group members for speaking up clearly.  There
> is a rough (quite clear) consensus for standardizing one dataplane
> solution to compressing segment routing over IPv6.
>
> As chairs, there are some related observations we need to make.
> There appears to be significant interest in using the framework in the
> CSID draft for addressing the above.
>
> However, before we issue a call for adoption on that, the chairs would
> like to understand how the working group wants to solve a technical
> problem.  The CSID draft contains two dataplane solutions.  The above
> rough consensus is for one dataplane solution.  Does the working group
> want to choose one?  Do the authors want to suggest that one of the two
> is the one we should standardize, and get working group agreement?
> Should we adopt the document, with a note indicating the problem, and
> solve the problem afterwards?  (That itself does not solve the problem,
> it merely kicks it down the road.) Do folks see another means to avoid
> putting the WG in conflict with itself?
>
> As a loosely related side node, the chairs will also observe that we do
> not see an obstacle to informational or experimental publication of
> other solutions, as long as there is sufficient energy in the working
> group to deal with those.  Also, only documents for which there is at
> least one implementation will be progressed this way.
>
> Thank you,
> Bruno, Jim, and Joel
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>