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-filsfilscheng-spring-srv6-srh-compression. We, at Arrcus have implemented CSID solution on the following hardware Products: Arrcus Quanta (IXAE, IXA) Broadcom Jericho-2 based platforms. Arrcus Edgecore (AS7962) Jericho-2 based platforms.

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

I oppose for the same reasons as well. From: spring On Behalf Of Tarek Saad Sent: Friday, October 8, 2021 12:05 AM To: James Guichard ; SPRING WG Cc: spring-cha...@ietf.org Subject: Re: [spring] WG Adoption call for

Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

On Thu, Oct 14, 2021 at 2:07 PM Brian E Carpenter wrote: > > On 14-Oct-21 22:41, Ted Hardie wrote: > > On Wed, Oct 13, 2021 at 9:28 PM Brian E Carpenter > > mailto:brian.e.carpen...@gmail.com>> wrote: > > > > > > > > Including semantics *of any kind* in an IP address is a very fundamental >

Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

On 14-Oct-21 22:41, Ted Hardie wrote: > On Wed, Oct 13, 2021 at 9:28 PM Brian E Carpenter > mailto:brian.e.carpen...@gmail.com>> wrote: > > > > Including semantics *of any kind* in an IP address is a very fundamental > change to the concept of

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

Dear WG and the WG Chairs, The draft https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

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

Joel, Thank you for your email. The ADs and chairs have been discussing. One thing that would be very helpful to our discussions would be some worked examples of the various C-SID behaviors, showing some SRv6 datagrams and what happens to their contents as they move across some suitable example

Re: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02

Hi Stefano, We agree on the overarching point, which is that the statement isn’t clear as written. I take your point about reading it in the context of SRv6 Network Programming, and I would absolutely agree that it’s right to talk about “the Network Programming paradigm”, but right now I

Re: [spring] CSID proposed clarifications

(Apologies if this appears twice - seems something went screwy with my outbound address so the other version of this is moderated) Darren, I'm a little confused here reading this - but all said and done - on the next behavior - how is this different from doing something along the lines of

[spring] CSID proposed clarifications

The NEXT-C-SID and REPLACE-C-SID flavors are functionally very similar. In both cases the SID in the IPv6 Destination Address (DA) contains an argument, that argument is used to construct the next SID from the active segment in the SRH Segment List. I believe the following pseudocode is a much

Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

On 13. Oct 2021, at 22:26, Brian E Carpenter wrote: > > Including semantics *of any kind* in an IP address is a very fundamental > change to the concept of IP. I may be wrong, but I'm not aware that any > RFCs prior to SRV6 have done this, and the founding reference for what > an address *is*

Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

On Wed, Oct 13, 2021 at 9:28 PM Brian E Carpenter < brian.e.carpen...@gmail.com> wrote: > > > Including semantics *of any kind* in an IP address is a very fundamental > change to the concept of IP. Would you mind elaborating what you mean by

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

Hi, Dear WG I support the adoption of this draft. From the user point of view, I think the CSID proposes a highly efficient way for SRv6 compression, and it can make the network programming model (RFC8986) be easier to deploy. CSID is just adding the next and replace flavors and still

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

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

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

Hi, I support the adoption of this draft. While SRv6 has high potential, for a simple operation such as TE the high packet length overhead of SRv6 has been an issue for operators. This draft resolves this issue and  (I believe) a necessary feature for operators, so we would like to support

[spring] SRV6 based compression standardization - https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear Spring WG I am Hasitha from Dialog which is the largest telecommunication Operator in Sri Lanka. We are in the process of migrating dialog IP network in to SRv6 . With this paradigms standardization of SRv6 compression is an indispensable task. Dialog IP network is a multivendor network