Subject: Re: [spring] SRv6 compression

From: linchangwang <[email-masked]>
Date: Mon, 2 Aug 2021 11:41:59 +0000

Hi All

Excellent work done by DT in the past year!
Many thanks for DT's hard work completing SRv6 header compression requirements and solutions comparion.
I hop the solution is the one that has been implemented by the most vendors in the world, which is CSID.

Best Regards,
Changwang

发件人: spring [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2021年7月31日 16:38
收件人: Henderickx, Wim (Nokia - BE/Antwerp); [email-masked]
主题: Re: [spring] SRv6 compression

Agree. Picking 1 solution to satisfy our requirements will benefit both the vendors and the operators.

Best Regards,
Zhenqiang Li
________________________________
[email-masked]

From: Henderickx, Wim (Nokia - BE/Antwerp)<mailto:[email-masked]>
Date: 2021-07-27 15:11
To: [email-masked]<mailto:[email-masked]>
Subject: [spring] SRv6 compression
Given the design team accomplished the work on providing requirements and analysis to compress an SRv6 SID list, I would recommend we pick 1 solution similar to what was done in NVO3 (when we discussed GENEVE, GUE, GPE, etc) given this has to be implemented in HW..

I hope we can conclude on this asap and move forward on this topic

-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
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: Boris Hassanov <[email-masked]>
Date: Tue, 3 Aug 2021 15:00:27 +0000 (UTC)

Hi all,
I do agree with the point that single solution is better than four of them in real multi-vendor network.From operator point of view it will be nightmare to deliver interop even with two different solutions from different vendors.
There are issues even with single standardized thing as you may know.
Thus +1 for single compression solution.
SY,Boris 

    On Tuesday, August 3, 2021, 04:50:42 PM GMT+3, Ville Hallivuori <[email-masked]> wrote:  
 
 Hello,

I would strongly prefer a single solution. While I am not particular on which of the solutions is selected, DT does make compelling argument for CSID.

I work for a vendor and would hate to have to implement multiple different header compression schemes. Especially if it comes out of limited microcode resources. While IETF has a long history of having two competing solutions (LDP/RSVP-TE, OSPF/ISIS), having competing options in forwarding plane is even less desirable than it is on the control plane.

Thanks for the DT for their excellent work.
BR,
Ville Hallivuori

On Sat, 31 Jul 2021, at 00:06, Voyer, Daniel wrote:

I agree as well – DT spent a year to come up with an analysis and now have a conclusion. In my view, we are ready to move with a single standard solution. This will unlock the vendors community to adopt an SRv6 compression standard and allow operators to move forward.

At the end of the analysis document, CSID seems to be the clear winner.

Thanks

dan

From: spring <[email-masked]> on behalf of Eduard Metz <[email-masked]>
 Date: Friday, July 30, 2021 at 7:24 AM
 To: Gyan Mishra <[email-masked]>
 Cc: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>, "Aissaoui, Mustapha (Nokia - CA/Ottawa)" <[email-masked]>, "[email-masked]" <[email-masked]>, Wim Henderickx <[email-masked]>
 Subject: [EXT]Re: [spring] SRv6 compression

Agree.

The DT has done a great job in the analysis. 

Moving forward with a single, standards track solution is preferred/required for interoperable SRv6 implementations.

cheers,

  Eduard

 

On Tue, Jul 27, 2021 at 6:09 PM Gyan Mishra <[email-masked]> wrote:

For all operators around the world looking at deployment of SRv6 compression and being in a  holding pattern waiting for SRv6 compression to be standardized by the IETF.  

Given the ubiquitous importance of SRV6 compression and MSD issues with long strict SR-TE explicit route object,  it is critical for interoperability for all steering use cases that exist today: enterprise, internet, private, access network - 5G wireless xHaul, mobile core, wireline, MBB, FBB. 

We as a WG need a single standardized solution for SRv6 compression for interoperability to work and all vendors marching to the same sheet of music.  

I agree that the NVO3 - GENEVE is a solid precedence path forward to take and for Spring WG to come to consensus and standardize on one solution and progress the other solutions as informational if implementations already exist.

Kind Regards 

Gyan 

Verizon Inc

On Tue, Jul 27, 2021 at 10:12 AM Aissaoui, Mustapha (Nokia - CA/Ottawa) <[email-masked]> wrote:

Same here. We want a single standard method of SID compression to allow the WG to focus on finalizing it and get vendors hardware implementations updated.

Regards,

Mustapha.

From: spring <[email-masked]> On Behalf Of Rabadan, Jorge (Nokia - US/Mountain View)
 Sent: Tuesday, July 27, 2021 4:54 AM
 To: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; [email-masked]
 Subject: Re: [spring] SRv6 compression

I agree with Wim’s statement that the precedent in NVO3 *could* apply here too: pick one solution as Standard’s track RFC, and once it is done, the others might be documented as Informational RFCs if they have implementations.

That would help the industry to move forward.

Thanks.

Jorge

 

From: spring <[email-masked]> on behalf of Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>
 Date: Tuesday, July 27, 2021 at 9:11 AM
 To: [email-masked] <[email-masked]>
 Subject: [spring] SRv6 compression

 

 

_______________________________________________
 spring mailing list
 [email-masked]
 https://www.ietf.org/mailman/listinfo/spring

--

Gyan Mishra

Network Solutions Architect 

Email [email-masked]

M 301 502-1347

_______________________________________________
 spring mailing list
 [email-masked]
 https://www.ietf.org/mailman/listinfo/spring

_______________________________________________
spring mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spring

_______________________________________________
spring mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spring