On Fri, 12 Apr 2024, 07:54 Shah, Himanshu, <hshah=40ciena....@dmarc.ietf.org> wrote:
> 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/. > Experimental. > > > 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> > 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 > 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 [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 >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
