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

Hi Francois Most Welcome! Responses in-line Kind Regards Gyan On Wed, Oct 13, 2021 at 6:53 AM Francois Clad (fclad) wrote: > Hi Gyan, > > > > Thanks for your feedback. The authors will work on some more illustrations > to add in the draft. > Gyan> Excellent! In my previous email (

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

Hi Chengli Most welcome! Overall the main point I would like to make that needs to be addressed more clearly in the draft is the interoperability between NEXT and REPLACE SID and a visual diagram of how that would look for same or different SID lengths. As these interoperability permutations

[spring] spring - Requested session has been scheduled for IETF 112

Dear Bruno Decraene, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. spring Session 1 (2:00 requested) Monday, 8 November 2021, Session I 1200-1400 Room Name: Room 5 size: 505

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

Hello Erik, You may find some examples here: https://datatracker.ietf.org/doc/draft-clad-spring-srv6-srh-compression-illus/ Hope this helps. Thanks, Francois From: spring on behalf of Erik Kline Date: Thursday, 14 October 2021 at 19:06 To: Joel M. Halpern Cc: spring@ietf.org ,

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

Joel, 1. Does the placement of a list of sids in the IPv6 DA field change the IPv6 architectural description of that field. To this I would say 100% yes – Section 2 of RFC8200 defines an address as “an IPv6-Layer identifier for an interface or a set of interfaces” and right above that it

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

On Fri, Oct 15, 2021 at 12:14 AM Mark Smith wrote: > > > > On Fri, 15 Oct 2021, 17:18 , wrote: >> >> Hi Joel , all, >> >> C-SID is no more than another mechanism that relies on some algorithmic >> mapping embedded in the IPv6 address. We do have already many of such >> algorithmic approaches:

[spring] short term plan regarding adoption call for draft-filsfilscheng-spring-srv6-srh-compression

Given this note from the 6man leadership, and its indication of more information by the middle of next week, I am going to leave the adoption call open till we get that information. If their update is significantly delayed, I will have to decide what to do next. Assuming they do update us, I

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

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:  ·

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

Hi all, I support the adoption of this draft which goes in line with the conclusions of the DT analysis, as the basis for a compression solution defined by the WG. I'm planning to perform interop tests in the forthcoming months, so further operational feedback can be provided afterwards. Best

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

On Thu, Oct 14, 2021 at 10:06 PM Brian E Carpenter < brian.e.carpen...@gmail.com> wrote: > On 14-Oct-21 22:41, Ted Hardie wrote: > > On Wed, Oct 13, 2021 at 9:28 PM Brian E Carpenter < > brian.e.carpen...@gmail.com > wrote: > > > > > > > > Including

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

Re: [spring] CSID proposed clarifications

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 Da[loc_bits/8] << sid_size Because - when I trace this all out into actual C code - that's pretty much what it seems to summarize down

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] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Hi Mark, Not sure what is incorrect in what I mentioned. Checksum neutrality is a distinct issue than the original question from Joel. That was discussed in the RFCs cited in the previous message. That’s said, I’m not sure that’s an issue for SRH given that the encap will need to be updated

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

On Fri, 15 Oct 2021, 17:18 , wrote: > Hi Joel , all, > > C-SID is no more than another mechanism that relies on some algorithmic > mapping embedded in the IPv6 address. We do have already many of such > algorithmic approaches: RFC6052, RFC7597, etc. That's not correct. DAs aren't expected to

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

Hi Joel , all, C-SID is no more than another mechanism that relies on some algorithmic mapping embedded in the IPv6 address. We do have already many of such algorithmic approaches: RFC6052, RFC7597, etc. The internal structure would be problematic if it requires that every intermediate node