All – I agree with Ketan/Boris and the points they have made (no need to repeat them again). In general, srh-compression technology has been accepted, implemented and deployed by many vendors and service providers. The issue of some legacy nodes not being able to ascertain final destination and conducting and failing upper layer checksum verification does not seem to have been widely reported, which is not to claim as not legit, but to support the argument that it is not wide spread but perhaps not significant enough to prevent the adoption of this technology.
It might be adequate enough to add ‘apology’ section to acknowledge such limitation, in order to progress the adoption of this document. I believe there is a precedence – section 7 of https://datatracker.ietf.org/doc/draft-ietf-6man-comp-rtg-hdr/. Thanks, Himanshu From: spring <spring-boun...@ietf.org> on behalf of Boris Hassanov <bhassanov=40yahoo....@dmarc.ietf.org> Date: Monday, April 8, 2024 at 12:44 PM To: Alvaro Retana <aretana.i...@gmail.com> Cc: SPRING WG List <spring@ietf.org>, spring-cha...@ietf.org <spring-cha...@ietf.org> Subject: [**EXTERNAL**] Re: [spring] C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression) Hi Alvaro and all, I re-read section 6.5, it seems to be clear enough IMO, it also has link towards section 9.2 (ICMP Error processing). I do agree with Ketan's email about the methodology for splitting all nodes into those 3 categories (Source, Transit, Destination). Indeed those concerns were about some transit nodes (especially legacy, Special Transit Node as Ketan said) which may experience issues with upper layer checksums and they also cannot deliver the behavior per section 9.2. I have discussed such potential issue with some colleagues and they told that for modern applications there such as eBPF based it is not an issue at all to make correct checksum handling. I also found some public references for that such as: https://github.com/facebookincubator/katran/tree/main [github.com]<https://urldefense.com/v3/__https:/github.com/facebookincubator/katran/tree/main__;!!OSsGDw!NigVX2MITPjUv5es_hCerGiVQWYxbzo2f0c9dlpVV4Q41fSk37U--WWnWdpgNM6asmUyT47YmNQNBGmnuMAT6k7TBoQ$> (katran/lib/bpf/csum_helpers.h). But additional research and experiments are needed. Anyway it is beyond the scope of this draft. May be we can just mention about such possibility for non-SRv6 aware Special Transit Nodes in 6.5 and that would be enough to inform implementers and operators in advance. SY, Boris On Monday, April 8, 2024 at 07:06:12 PM GMT+3, Ketan Talaulikar <ketant.i...@gmail.com> wrote: Hi Alvaro, I find some level of confusion on the discussion threads and it might perhaps be due to the inconsistent use of terminologies. It would help to use the correct terminologies from RFC8754 (6man WG RFC) to bring clarity on what is within the scope and what is beyond the scope of this document. a) SR Source Node: the node originating the packet - it may have an SRH or may skip it (section 4.1) b) Transit Node: node doing IPv6 forwarding c) (Ultimate) Destination Node (from RFC8200): the final node to which the packet is destined The CSID document in section 6.5 does not change or update the text in RFC8200 sec 8.1. It is simply stating what the "final destination" is going to be when CSID is used because RFC8200 does not talk about RHs in sec 8.1. RFC8754 covered this aspect by specifying that the last segment is the "final destination" but this needs to be specified when using C-SID (with or without SRH) and for all C-SID flavors/behaviors. I find the current text in section 6.5 to be necessary and sufficient for implementations that claim (or need to) support SR Source Node behavior for C-SIDs. The CSID document does not change any behavior at the Transit Node or for the (Ultimate) Destination Node. Therefore, the discussion of Transit Nodes is outside the scope of this document - just as it was outside the scope for RFC8754. Now, if some "Special Transit Node" wants to go beyond RFC8200 and do things like upper layer checksum validation enroute then they can refer to the same text in section 6.5 to first understand CSID processing and to do what is necessary for their packet processing enroute. This requires such "Special Transit Nodes" to be aware of first SRv6 and now C-SID - this is the same for any new packet encoding technology. It seems like we are putting the cart before the horse when raising concerns about existing implementations that are not SRv6 and C-SID aware of not being able to do their processing. Let us publish the C-SID document so implementers of those "Special Transit Nodes" (also being referred to as middleboxes on some threads) have a reference to upgrade for C-SID support. Finally, I’ve not heard of issues related to these "Special Transit Nodes" from operators that have deployed SRv6. That may be a good discussion to have (again outside the scope of this document and perhaps in srv6ops?) - so operators who have SRv6 deployment experience can share their learnings and best practices. Thanks, Ketan On Thu, Mar 28, 2024 at 5:34 PM Alvaro Retana <aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>> wrote: Section 6.5 of draft-ietf-spring-srv6-srh-compression describes the behavior when an originating node inside an SRv6 domain creates a packet with a C-SID as the final destination. This description differs from the text in Section 8.1 of RFC8200. We plan to send the draft to the 6man WG for review and explicitly highlight this difference. Please comment on the text in Section 6.5. Does anything need to be added, deleted, changed, or clarified? We want to ask for feedback soon; please send comments on this topic by April 5th. Thanks! Alvaro. -- for spring-chairs _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring [ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!OSsGDw!NigVX2MITPjUv5es_hCerGiVQWYxbzo2f0c9dlpVV4Q41fSk37U--WWnWdpgNM6asmUyT47YmNQNBGmnuMATcBToP6c$> _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring [ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!OSsGDw!NigVX2MITPjUv5es_hCerGiVQWYxbzo2f0c9dlpVV4Q41fSk37U--WWnWdpgNM6asmUyT47YmNQNBGmnuMATcBToP6c$>
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
