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

Maybe just to clarify my statement. in my view we can adopt CSID and discuss the matter of 1 versus 2 data-planes during the WG and see how to move forward from here. At least we can make progress on this matter.

From: spring <spring-bounces@ietf.org> on behalf of Henderickx, Wim (Nokia - BE/Antwerp) <wim.henderickx@nokia.com>
Date: Wednesday, 8 September 2021 at 05:53
To: Joel M. Halpern <jmh@joelhalpern.com>, spring@ietf.org <spring@ietf.org>
Subject: Re: [spring] Conclusion from WG poll on dataplane solution for compressing segment routing over IPv6
Joel and chairs thx for having us move forward here. On the q if CSID is 1 dataplane or 2 dataplane, in my view there is 2 dataplanes inside the CSID proposal and I am advocating that in case CSID moves fwd we pick 1 of them, not both.

From: spring <spring-bounces@ietf.org> on behalf of Joel M. Halpern <jmh@joelhalpern.com>
Date: Monday, 6 September 2021 at 19:27
To: spring@ietf.org <spring@ietf.org>
Subject: [spring] Conclusion from WG poll on dataplane solution for compressing segment routing over IPv6
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