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

Dear Chairs & WG

As the authors have described the C-SID draft is a single solution for the
SRv6 data plane  compression solution with two different endpoint flavors
for SRv6 PGM Endpoint behaviors End and End.x, called NEXT-C-SID &
REPLACE-C-SID, similar to existing SRv6 PGM endpoint flavors PSP, USP, USD.

C-SID is a combination of the two drafts below:

C-SID
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Combination of the two drafts below:

G-SID - Generalized SID
https://datatracker.ietf.org/doc/html/draft-cl-spring-generalized-srv6-for-cmpr-03

G-SID is renamed to C-SID and G-SRv6 compression sub path is renamed to
C-SID Sequence in REPLACE-C-SID endpoint flavor in the above C-SID draft.

G-SID container concept and breaks out the common locator part of the SRv6
SID and trailing bits for the encapsulation header savings.
G-SID draft section 8 shows interoperability  status applied to the C-SID
draft.

SRv6 uSID micro-segment
https://datatracker.ietf.org/doc/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-10

uSID is renamed to NEXT-C-SID endpoint flavor in the above C-SID draft.

uSID Micro-segment introduces a LIB and GIB local uSID and Global uSID
concept of IDs within a container.

C-SID draft  introduces a new endpoint flavor option which is a combination
of the two drafts above called NEXT-AND-REPLCE-CSID which provides the best
efficiency in encapsulation size with increased complexity.

Kind Regards

Gyan

On Mon, Sep 13, 2021 at 8:30 AM <liu.aihua@zte.com.cn> wrote:

>
> Dear Chairs & Weiqiang,
>
> As I presented before, the CSID draft is just only one solution with two
> different flavors. Even there are some others, the CSID has the most
> supporters and has finished multi-vendor interworking test and field test,
> including my company ZTE. Especially, CSID is the most compatible the
> standard SRv6 dataplane. It's benificial for SRv6 industry if the WG could
> adopt the CSID draft.
>
>
> Best regards,
>
> Aihua
>
>
> 原始邮件
> *发件人：*WeiqiangCheng
> *收件人：*'Joel M. Halpern';spring@ietf.org;
> *日 期 ：*2021年09月08日 11:25
> *主 题 ：**Re: [spring] Conclusion from WG poll on dataplane solution for
> compressing segment routing over IPv6*
> Dear Chairs,
>
> Many thanks for your hard working.
>
> We are happy to see that the CSID draft has significant interest to be
> adopted as a WG document.
>
> Regarding the dataplane, the authors believe that the CSID draft contains
> only one dataplane solution with two different flavors[1]: NEXT-CSID-FLAVOR
> and REPLACE-CSID-FLAVOR, rather than two dataplane solutions.
>
> Both the flavors are defined based on the SRv6 data plane(one data plane),
>
> and the SIDs with these two flavors can be encoded in a single SRH just like
> we can encode PSP Flavor SIDs and USD flavor SIDs together in a SRH.
>
> The inter-op test of CSIDs had been done almost one year ago[2], and
> everything was OK.
>
> Furthermore, the mechanism defined in the draft has been stable and mature.
>
> With the consensus, the authors hope WG can consider to adopt the CSID
> draft.
>
> Best regards,
> Weiqiang
> on behalf of CSID authors
>
> [1]. https://datatracker.ietf.org/doc/html/rfc8986#section-4.16
> [2].
>
> https://datatracker.ietf.org/doc/html/draft-filsfilscheng-spring-srv6-srh-co
> mpression-02#section-11
>
>
>
> -----邮件原件-----
> 发件人: spring [mailto:spring-bounces@ietf.org] 代表 Joel M. Halpern
> 发送时间: 2021年9月7日 01:27
> 收件人: spring@ietf.org
> 主题: [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
>
>
>
> _______________________________________________
> 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
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*