Re: [spring] [**EXTERNAL**] Re: C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression)

On Fri, 12 Apr 2024, 07:54 Shah, Himanshu, <hshah=40ciena.com@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-bounces@ietf.org> on behalf of Boris Hassanov
> <bhassanov=40yahoo.com@dmarc.ietf.org>
> *Date: *Monday, April 8, 2024 at 12:44 PM
> *To: *Alvaro Retana <aretana.ietf@gmail.com>
> *Cc: *SPRING WG List <spring@ietf.org>, spring-chairs@ietf.org <
> spring-chairs@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.ietf@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.ietf@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
>