Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

From: Qiuyuanxiang <[email-masked]>
Date: Sat, 2 Oct 2021 07:20:01 +0000

I understand that CSID draft defines the NEXT and REPLACE behaviors, but they present a single SRv6 data plane based solution.
I totally support the adoption call.

发件人: spring [mailto:[email-masked]] 代表 James Guichard
发送时间: 2021年10月1日 22:05
收件人: SPRING WG <[email-masked]>
抄送: [email-masked]
主题: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

The chairs would like to express their appreciation for all the responses received to our emails with reference to how the working group wishes to move forward with respect to a solution for SRv6 compression.

The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis for its compression standardization work. That is part of what this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ but with some clear guidelines as follows. By expressing support for adoption of this document you are fully aware of and are acknowledging that:

  1.  The SPRING working group is adopting a document that has multiple SRv6 Endpoint behaviors.
  2.  The document is a “living” document; it may change as it goes through review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed BEFORE said document is allowed to progress from the working group to publication. A list of these discussion points will be documented in the WG document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as part of the adoption call that the following text describing an open issue be added to the document in the above-described open issues section:
     *   "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.".

Please consider the above guidelines as you decide on whether to support or not this WG adoption. Please express clearly your reasoning for support/non-support as well as any open discussion points you would like addressed should the document be adopted into the working group.

Thanks!

Jim, Bruno & Joel

-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, which is
intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender
by phone or email immediately and delete it!

---

From: linchangwang <[email-masked]>
Date: Sun, 3 Oct 2021 08:11:20 +0000

Dear WG:

     I strongly support the adoption.
We implemented the C-SID solution, and it works very well. From an design engineers perspective, CSID is a single SRv6 based data plane solution.
The draft is ready for the WG adoption.

Thanks!

Changwang Lin

New H3C.

收件人: SPRING WG

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: "Bernier, Daniel" <[email-masked]>
Date: Thu, 7 Oct 2021 18:22:54 +0000

Hi,

After re-reading the draft I strongly support its adoption.

  1.  Following the Design Team work stream, CSID proves conformant and optimal.
  2.  It allows for the flexibility of selecting the SRv6 data plane flavor (compressed or not) without changes to the architecture.
  3.  Has proven quite easy to implement with our existing HW platforms (in a matter of hours for some ASICs)
  4.  As my colleague Dan Voyer pointed out, we successfully deployed in production with live traffic.  And in a multi-vendor environment.

Thanks,

Dan B

From: spring <[email-masked]> on behalf of James Guichard <[email-masked]>
Date: Friday, October 1, 2021 at 10:05 AM
To: SPRING WG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [EXT][spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

·         "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.".

Thanks!

Jim, Bruno & Joel

---

From: Srihari Sangli <[email-masked]>
Date: Fri, 8 Oct 2021 14:58:49 +0000

Hello Chairs,

This document describes 3 behaviours for SID and this in contradiction to what was discussed on SPRING alias about adopting one behaviour for which there was overwhelming response.

I strongly object the adoption of this draft.

srihari…

On 01/10/21, 7:35 PM spring on behalf of James Guichard from [email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]> said >

[External Email. Be cautious of content]

Dear WG:

The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/__;!!NEt6yMaO-gk!VqQ4-F83ursUSxG6IyMfQKNJaaO-BlMBILomM7BkKFUjju3onMCHbgMNQKaWuK4$> as the basis for its compression standardization work. That is part of what this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/__;!!NEt6yMaO-gk!VqQ4-F83ursUSxG6IyMfQKNJaaO-BlMBILomM7BkKFUjju3onMCHbgMNQKaWuK4$> but with some clear guidelines as follows. By expressing support for adoption of this document you are fully aware of and are acknowledging that:

Thanks!

Jim, Bruno & Joel

Juniper Business Use Only

---

From: "Swadesh Agrawal (swaagraw)" <[email-masked]>
Date: Fri, 8 Oct 2021 18:37:04 +0000

Hi Chairs, WG,

RFC8986 defines multiple flavors for the End, End.X, and End.T SIDs. CSID draft adds next and replace flavors for these SIDs for SRv6 compression in conformance to RFC8986. CSID is a single SRv6 based data plane solution

I strongly support the WG adoption call.

Regards
Swadesh

From: spring <[email-masked]> on behalf of James Guichard <[email-masked]>
Date: Friday, October 1, 2021 at 7:04 AM
To: SPRING WG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Tianran Zhou <[email-masked]>
Date: Mon, 11 Oct 2021 08:42:44 +0000

Hi Chairs and WG,

I strongly support the adoption of this draft.

As far as I know, there are already multiple vendors(10+) support CSID and passed the interoperation test.
I followed the DT for a while. CSID as a SRv6 native solution, shows great advantages than CRH.
This draft is mature enough to be adopted by the WG, as the baseline for further development.

Cheers,
Tianran

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Wed, 13 Oct 2021 14:07:12 +0000

Hi SPRING，

Sorry for the late response due to the National days break. It seems like I miss a lot of discussion, and it did cost me a lot of time to read all the threads.

As a member of the design team, and a person who participates in IETF SR standards for a long time,  I know who how difficult for us to get here. Many thanks for the contributions from anyone.

From the outputs of DT team, we know that CSID meets all the requirements and provide the best performance. As an author of CSID draft, I can say that over 10 vendors have implemented CSID, which proves that CSID has been adopted by the industry very well. Therefore, no matter from the aspect of rough consensus and running code, I do think we should adopt CSID and it is the right way for sure. Also, from many polls in the mailing list, we also see the consensus of using CSID as the basis of SRv6 compression standard.

Till now, many our customers have chosen the CSID as the SRv6 compression solution, and some inter-op test and trial deployment have been finished even one year ago in CMCC’s lab and live network, and we will have more product network deployments in the near future. It proves that CSID can work very well in the product network. Many thanks for the customers and partners who choose CSID in their networks and products.

There may be some issues discussed in the mailing list, that is good! It also proves that people are interested in the topic as well, we are very welcome anyone to make the contributions to the solution, and let’s do it together to produce a good solution for the industry, that is what we are doing all the long way. Therefore, also thanks to the people provide comments in the mailing list. Will reply to the mailing list to answer the questions ASAP.

At the end, as an author, the member of the design team, and a person who focus on SR standards for a long time, I strongly support the CSID adoption.

Respect,
Cheng

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Giuseppe Siracusano <[email-masked]>
Date: Fri, 15 Oct 2021 10:25:53 +0200

Dear WG, WG Chairs,

I support the adoption of draft-filsfilscheng-spring-srv6-srh-compression.

I have been working on SRv6 for different research project over the last
years.
The flavors defined in the CSID draft are complaint with RFC8986 and builds
on top of the single SRv6 dataplane.

Thanks
Giuseppe Siracusano, PhD

Dear WG:

The chairs would like to express their appreciation for all the responses
received to our emails with reference to how the working group wishes to
move forward with respect to a solution for SRv6 compression.

The apparent inclination of the working group is to use
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
as the basis for its compression standardization work. That is part of what
this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for
adoption ending October 15th for
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
but with some clear guidelines as follows. By expressing support for
adoption of this document you are fully aware of and are acknowledging
that:

   1. The SPRING working group is adopting a document that has multiple
   SRv6 Endpoint behaviors.
   2. The document is a “living” document; it may change as it goes through
   review and analysis by the SPRING working group.
   3. All open discussion points raised on our mailing list MUST be
   addressed BEFORE said document is allowed to progress from the working
   group to publication. A list of these discussion points will be documented
   in the WG document and maintained by the document editor in conjunction
   with the chairs.
   4. If this document is adopted by the working group, the chairs specify
   as part of the adoption call that the following text describing an open
   issue be added to the document in the above-described open issues section:
      - "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.".

Please consider the above guidelines as you decide on whether to support or
not this WG adoption. Please express clearly your reasoning for
support/non-support as well as any open discussion points you would like
addressed should the document be adopted into the working group.

Thanks!

Jim, Bruno & Joel