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

From: "Bertrand Duvivier (bduvivie)" <[email-masked]>
Date: Fri, 15 Oct 2021 15:01:52 +0000

Dear Working Group,

I would like to confirm that Cisco participated to the interops mentioned by Shay. They were all successful and led to deployments.

I would like to remind that Cisco has been shipping products supporting this draft for ~10 months, across our hardware product line: 
·         NCS 5500
·         NCS 560
·         NCS 540
·         NCS 540-L
·         ASR 9000 (Tomahawk)
·         ASR 9000 (LightSpeed)
·         NCS 5700 (Near FCS)
·         Silicon One - 8000 (Near FCS)
·         XR9000 (virtual)

I would also like to remind that Cisco and Rakuten have publicly communicated on the commercial deployment of the technology specified in this draft. Furthermore, the technology is also deployed in production with live traffic in Bell Canada’s network in a multivendor environment. There are additional undisclosed deployments.

I strongly support the adoption of this draft

On 14 Oct 2021, at 10:48, Shay Zadok <shay.zadok=[email-masked]<mailto:shay.zadok=[email-masked]>> wrote:

Dear WG,

We would like to update on the production support by the StrataDNX products of both flavors REPLACE and NEXT as defined in CSID draft, as well as non-compressed "Classic" SRv6.
StrataDNX products include: Jericho2/Jericho2c/Qumran2c/Qumran2a/Qumran2u/Qumran2n/Jericho2c+ and any future device

This support keeps:
1. Single and unified data-plane uCode, programmed using high level language
2. Single data-plane API
3. Concurrent/Simultaneous support of all three techniques based on a per-packet behavior
4. Concurrent/Simultaneous support of all three techniques inside of the same SRv6 Header
5. In all three techniques the following is already supported concurrently/simultaneously and in production
    1. SRv6 main behaviors - compliant with rfc8986
    2. SRv6 insert behaviors - compliant with draft-srv6-net-pgm-insertion
    3. SRv6 midpoint protection behaviors - compliant with draft-midpoint-protection

All of the above is in production deployment in various published and unpublished networks around the globe.
Our products are used by industry leading OEM (some of them published they are using the StrataDNX products) and "pure" NOS vendors.

BRCM using Jericho2 participated in couple of interops that included some mix of REPLACE-CSID, NEXT-CSID and non-compressed "Classic" SRv6 - and all interops have ended successfully

Thanks & Regards,
Shay

发件人: spring [mailto:[email-masked]<mailto:[email-masked]>] 代表 James Guichard
发送时间: 2021年10月1日 22:05
收件人: SPRING WG <[email-masked]<mailto:[email-masked]>>
抄送: [email-masked]<mailto:[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 electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it._______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: "蒋治春(若弈)" <[email-masked]>
Date: Sat, 16 Oct 2021 16:23:11 +0800

Hi Dear WG，

I support the adoption of this draft.
I think this proposal merges the G-SID and micor-SID mechanizm successfully based on the standardized SRH format and gets well support by the main stream chip vendor. It does help reducing the SRv6 SID size in a brilliant way.

Thanks

BR
Roy Jiang
Network Architect@Alibaba Cloud

​

 ------------------原始邮件 ------------------
发件人:spring <[email-masked]>
发送时间:Fri Oct 15 23:03:33 2021
收件人:[email-masked] <[email-masked]>
抄送:[email-masked] <[email-masked]>, [email-masked] <shay.zadok=[email-masked]>, [email-masked] <[email-masked]>
主题:[spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear Working Group, 

 

On 14 Oct 2021, at 10:48, Shay Zadok <shay.zadok=[email-masked]> wrote:

Dear WG, 

This support keeps:

Thanks & Regards,
Shay

发件人: 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 SPRING working group is adopting a document that has multiple SRv6 Endpoint behaviors.
The document is a “living” document; it may change as it goes through review and analysis by the SPRING working group.
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.
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.".

Thanks!
 
Jim, Bruno & Joel

[email-masked]