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

Dear WG, I support the adoption of draft https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

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

Hi Chairs, I would not consider new flavors to the existing endpoint behaviors as multiple data planes. At least that's not what I thought of when responding to the earlier poll. Either way, this I-D is a good base for making progress. In fact, making sure that the I-D is in WG control is a much b

[spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

The SPRING working group is in the midst of an adoption call on https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/. The SPRING charter has text that is explicit that modifications to data planes and architectures standardized by other working groups may not be mo

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

Hi WG, We are working on SRv6 for many years, and a lots of innovations are built on SRv6. CSID uses the existing SRv6 data plane and control plane extensions to provide efficient encoding of SRH so that we can mitigate a lot of complexities and workload of implementation and standardization. T

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

Dear SPRING WG, I support this adoption for draft-filsfilscheng-spring-srv6-srh-compression. After I read the draft with the related DT documents, I understand that NEXT and REPLACE flavors comply with RFC8986, and satisfied all the requirements at high level. I really appreciate all DT members

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

Hi, I have read the draft and been following this discussion of SRH compression. Since the WG has agreed to address the SRH compression issue, the draft proposes a reasonable way to do that, and the quality of the document is above the average, IMHO. Therefore, I support the adoption of the do

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

Dear WG, The draft, as far as I can understand, defines REPLACE-CSID and NEXT-CSID flavours in order to enable efficient SRH encoding capability, and it is based on a single SRv6 data plane. I highly endorse the adoption of CSID as an operator who is going to deploy multi-vendors SRv6 in the ne

Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

Could somebody provide a copious set of *example* IPv6 addresses that conform to draft-filsfilscheng-spring-srv6-srh-compression? I means the actual addresses in standard IPv6 address notation (RFC5952) or just as 0x hex numbers. BTW, is there running code for srv6-srh-compression? Regards

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

I support the WG adoption of draft-filsfilscheng-spring-srv6-srh-compression. My research activity is related on leveraging SRv6 to implement a containerized SFC on Kubernetes. The new flavors added to the SR endpoint behaviors will be useful to this scope, simplifying the processing on each clu

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

Dear Chairs, I object to the WG adopting this draft. If SIDs are IPv6 addresses, then this draft is fundamentally relying on encoding a segment list of SIDs (with a common high order prefix), and therefore a list of multiple IPv6 addresses, in the IPv6 Destination Address field. Clearly the IPv6

Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

Good to hear. This doesn't address compatibility with 8200 and 4291 though, which seems to be the bit that's causing people concern. Nick Darren Dukes (ddukes) wrote on 12/10/2021 16:46: Hi Nick, during review of RFC8986, section 3.2 was added.  SID allocation follows that. Darren On 2021-

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

Hi WG, The draft is based on SRv6 data plane with flavors defined for SRv6 compression, as per RFC8986. It is coherent with the one data plane solution objective. I strongly support the adoption of the draft. Thanks, Mike. From: spring On Behalf Of James Guichard Sent: Friday, October 1, 2021

Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

Hi Nick, during review of RFC8986, section 3.2 was added. SID allocation follows that. Darren On 2021-10-12, 10:40 AM, "Nick Hilliard" wrote: Darren Dukes (ddukes) wrote on 12/10/2021 15:35: > Given this, it is clear, the CSID flavors of the same SRv6 SIDs defined > in RFC8986 are also IPv6

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

Hi WG, I support the adoption of draft-filsfilscheng-spring-srv6-srh-compression. I have spent a lot of time doing performance measurements for SRv6 dataplane implementations in open-source stack including Linux Kernel, VPP and others. The measurements included SRv6 behaviors defined i

Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

Darren Dukes (ddukes) wrote on 12/10/2021 15:35: Given this, it is clear, the CSID flavors of the same SRv6 SIDs defined in RFC8986 are also IPv6 addresses. Ok, this is good that we're all on the same page about SIDs being IPv6 addresses. This means that they and draft-filsfilscheng-spring-s

Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

This is an interesting conversation but I would like to restate something I mentioned early on. I'll try to say it differently this time. 1 - The CSID draft (draft-filsfilscheng-spring-srv6-srh-compression-02) does NOT alter the definition of an SRv6 SID as defined in RFC8754 and RFC8986.

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

Hi,  AllI’d like to  support the adoption of the draft https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/For CSID is a efficient solution based on the SRv6 data plane. And it provides a flexible choice of flavors when apply in different kinds of sce

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

Dear all, I support the adoption of this draft. I am Marco Bonola, senior researcher at CNIT (Italy), and I have recently worked on the SRv6 dataplane in the context of SmartNIC and in-Kernel acceleration. The new flavor designed in this draft compiles with the SRv6 dataplane and can be imple

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

Hi WG, I support the adoption of CSID draft. I have been working on developing a Kubernetes network datapath solution using the SRv6 network programming defined in RFC8986. I would like to thank the DT team for the hard work over the past months. The DT analysis doc shows the CSID solution out

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

I would like to express my support for the Compressed SRv6 Segment List Encoding in SRH draft. As an architect for one of the world’s largest Solutions providers, we have quite a bit of interest in this solution. I have been involved in SR since 2013 and have been following SRv6 implementation

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

Dear chairs and WG, I support the adoption of draft-filsfilscheng-spring-srv6-srh-compression. A SID compression mechanism is needed and this draft specifies one that is both efficient (as the DT documented) and consistent with standardized SRv6 architecture and dataplane. Thanks, Sébastien -