In my opinion, C-SID just presents 1 solution in dataplane, even it has 2
flavors, but they share the same framework and process. Before we accept it it
is not important to prefer which flavor.
Best regards，
Aihua
原始邮件
发件人：Henderickx,Wim(Nokia-BE/Antwerp)
收件人：Joel M. Halpern;[email protected];
日 期 ：2021年09月08日 11:53
主 题 ：Re: [spring] Conclusion from WG poll on dataplane solution for compressing
segment routing over IPv6
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
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 <[email protected]> on behalf of Joel M. Halpern
<[email protected]>
Date: Monday, 6 September 2021 at 19:27
To: [email protected] <[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
