Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

Hi Ketan, On Tue, 9 Apr 2024, 01:55 Ketan Talaulikar, wrote: > Hi Alvaro, > > I have some concerns about the second paragraph of your email. Compressed > SRv6 SIDs (C-SID) are still SRv6 and therefore everything from existing > SRv6 RFCs apply and those aspects are very much foundational to

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

Hi Alvaro, I have some concerns about the second paragraph of your email. Compressed SRv6 SIDs (C-SID) are still SRv6 and therefore everything from existing SRv6 RFCs apply and those aspects are very much foundational to this C-SID document as well. RFC8754 has introduced the omission of SRH

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

Le 2024-04-05 à 16:30, Tom Herbert a écrit : CAUTION:This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. On Fri, Apr 5, 2024, 8:53 AM Antoine FRESSANCOURT

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

Tom, So let me try to restate your point. You are saying that such ability to distinguish non encapsulated SR packet with uSIDs is needed only for devices which would capture some packets in the middle, trying to run checksum and failing. Is this so ? Are there any other reasons for this ? I

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

On Fri, Apr 5, 2024, 8:53 AM Antoine FRESSANCOURT wrote: > Hello, > > After reading RFC 8754 and RFC 8986 together with the draft (version 14), > it seems to me that the cases when the SRH will be omitted are quite > limited, and will happen among nodes sharing the same locator block. We can >

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

On Thu, Apr 4, 2024 at 2:50 PM Francois Clad wrote: > An SRv6-unaware middlebox will not be able to verify the upper-layer checksum > of SRv6 packets in flight, regardless of whether an SRH is present or not. > An SRv6 and C-SID aware middlebox will be able to find the ultimate DA and > verify

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

On Thu, Apr 4, 2024, 4:59 PM Robert Raszuk wrote: > > Well software could know that but not NICs nor ASICs ... > Robert, Sure they do. If a NIC or an ASIC wants to look at the transport layer then they'd have to parse over the Routing Header. So they *know* it's there, and the processing of

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

Well software could know that but not NICs nor ASICs ... On Thu, Apr 4, 2024 at 10:57 PM Tom Herbert wrote: > > > On Thu, Apr 4, 2024, 4:00 PM Robert Raszuk wrote: > >> Tom, >> >> I have full sympathy for your points. >> >> But I can not understand how suddenly SR uSID is the issue and normal

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

On Thu, Apr 4, 2024, 4:00 PM Robert Raszuk wrote: > Tom, > > I have full sympathy for your points. > > But I can not understand how suddenly SR uSID is the issue and normal IPv6 > vanilla Routing Headers are ok as defined checksum wise in RFC8200. > > Maybe someone could elaborate a bit on that

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

Bob Hinden wrote: > Suresh, > The prefix allocated in draft-ietf-6man-sids is not required to be > used. For example, from the Abstract: > This document allocates and makes a dedicated prefix available for > SRv6 SIDs. > There is not a MUST be used. Similiarly,

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

On Thu, Apr 4, 2024 at 3:54 PM Bob Hinden wrote: > Suresh, > > The prefix allocated in draft-ietf-6man-sids is not required to be used. > For example, from the Abstract: > > This document allocates and makes a dedicated prefix available for > SRv6 SIDs. > > There is not a MUST be used.

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

Tom, I have full sympathy for your points. But I can not understand how suddenly SR uSID is the issue and normal IPv6 vanilla Routing Headers are ok as defined checksum wise in RFC8200. Maybe someone could elaborate a bit on that ? Thx, R. PS. And of course in spite of all effort from Alvaro

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

Suresh, The prefix allocated in draft-ietf-6man-sids is not required to be used. For example, from the Abstract: This document allocates and makes a dedicated prefix available for SRv6 SIDs. There is not a MUST be used. Bob > On Apr 4, 2024, at 12:44 PM, Suresh Krishnan > wrote:

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

On Thu, Apr 4, 2024, 3:37 PM Ole Trøan wrote: > Tom, > > Can you point to any IETF specification requiring that middle boxes should > be able to validate a l4 checksum? IPsec be damn. It just seems like a > path we should not go down. > Ole, No, but neither can I point to an RFC that says

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

Hi Adrian, On Thu, Apr 4, 2024 at 3:11 PM Adrian Farrel wrote: > > If any allocation had been made (early or otherwise), I'd see it here > https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml > and here >

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

Tom,Can you point to any IETF specification requiring that middle boxes should be able to validate a l4 checksum? IPsec be damn.  It just seems like a path we should not go down. O. On 4 Apr 2024, at 21:22, Tom Herbert wrote:On Thu, Apr 4, 2024, 3:12 PM Robert Raszuk

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

Show me Broadcom's SDK which does this in DNX family and we can talk more about such option. Best, R. On Thu, Apr 4, 2024 at 9:22 PM Tom Herbert wrote: > > > On Thu, Apr 4, 2024, 3:12 PM Robert Raszuk wrote: > >> Tom, >> >> > SR aware routers to update L4 checksum >> >> That is completely

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

On Thu, Apr 4, 2024, 3:12 PM Robert Raszuk wrote: > Tom, > > > SR aware routers to update L4 checksum > > That is completely unrealistic. > > Show me the box which can forward all interfaces at 800 Gb/s and read > entire each packet and compute upper layer checksum on it. > Robert, It's not

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

Tom, > SR aware routers to update L4 checksum That is completely unrealistic. Show me the box which can forward all interfaces at 800 Gb/s and read entire each packet and compute upper layer checksum on it. If anything just do encap and move on. Thx, R. On Thu, Apr 4, 2024 at 7:06 PM Tom

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

If any allocation had been made (early or otherwise), I'd see it here https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml and here https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml right? A

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

Hi Tom, draft-ietf-6man-sids takes care of that [1]. As Michael suggested, tcpdump could use this block as a default with a CLI override for operators using a different one. [1] https://www.ietf.org/archive/id/draft-ietf-6man-sids-06.html#section-6 Thanks, Francois On 4 Apr 2024 at 19:12:26,

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

I agree with Francois’s point. Also, if the problem comes from middle box checksum, then I do not believe the problem exists. Why a transit node has the right to do so? If it is not an SRv6 Endpoint node, it should not try to do so. Btw, EU, USA and other countries may have the Easter holiday

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

Tom Herbert wrote: >> It wouldn't be that weird to have the new SID block in the source >> code, with an override from the command line. No weirder than port >> 23==telnet. >> > Michael, > 23 is well known port number registered with IANA? Is the SID block a >

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

On Thu, Apr 4, 2024, 1:12 PM Ole Troan wrote: > Tom, > > > Yes I am with you here. > > > > However let's observe that this is pretty common best practice to > disable any hardware offload on the box when running tcpdump or wireshark. > > > > In fact some implementations (F5) do it for you

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

On Thu, Apr 4, 2024, 1:08 PM Michael Richardson wrote: > > Tom Herbert wrote: > >> Tcpdump can determine that this packet is steered onto an SRv6 path > by > >> checking if the DA matches the SRv6 SID block. > > > That would require introducing external state to tcpdump for correct

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

Tom, > Yes I am with you here. > > However let's observe that this is pretty common best practice to disable any > hardware offload on the box when running tcpdump or wireshark. > > In fact some implementations (F5) do it for you automagically :) > > And as it has been said based on the

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

Tom Herbert wrote: >> Tcpdump can determine that this packet is steered onto an SRv6 path by >> checking if the DA matches the SRv6 SID block. > That would require introducing external state to tcpdump for correct > operation. This would be a major divergence in both

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

On Thu, Apr 4, 2024, 12:30 PM Robert Raszuk wrote: > Hi Tom, > > Yes I am with you here. > > However let's observe that this is pretty common best practice to disable > any hardware offload on the box when running tcpdump or wireshark. > > In fact some implementations (F5) do it for you

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

Hi Tom, Yes I am with you here. However let's observe that this is pretty common best practice to disable any hardware offload on the box when running tcpdump or wireshark. In fact some implementations (F5) do it for you automagically :) And as it has been said based on the fact that hardware

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

On Thu, Apr 4, 2024, 11:48 AM Francois Clad wrote: > Hi Tom, > > Tcpdump can determine that this packet is steered onto an SRv6 path by > checking if the DA matches the SRv6 SID block. > Francois, That would require introducing external state to tcpdump for correct operation. This would be a

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

Hi Tom, Tcpdump can determine that this packet is steered onto an SRv6 path by checking if the DA matches the SRv6 SID block. Thanks, Francois On 4 Apr 2024 at 16:59:59, Tom Herbert wrote: > > > On Thu, Apr 4, 2024, 9:39 AM Francois Clad wrote: > >> Hi Mark, >> >> Tcpdump/wireshark decodes

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

On Thu, Apr 4, 2024, 9:39 AM Francois Clad wrote: > Hi Mark, > > Tcpdump/wireshark decodes the IPv6 header just fine. I do not see any > issue here. > Francois, The problem is that tcpdump can't tell that a packet is an SR packet if there's no SRH. For instance, if the checksum is not

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

Hi Mark, Tcpdump/wireshark decodes the IPv6 header just fine. I do not see any issue here. Cheers, Francois On 4 Apr 2024 at 14:09:43, Mark Smith wrote: > > > On Thu, 4 Apr 2024, 22:50 Francois Clad, wrote: > >> Hi Alvaro, all, >> >> RFC 8754 allows the SR source node to omit the SRH when

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

On Thu, 4 Apr 2024, 22:50 Francois Clad, wrote: > Hi Alvaro, all, > > RFC 8754 allows the SR source node to omit the SRH when it contains > redundant information with what is already carried in the base IPv6 header. > Mandating its presence for C-SID does not resolve any problem because it >

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

Hi Alvaro, all, RFC 8754 allows the SR source node to omit the SRH when it contains redundant information with what is already carried in the base IPv6 header. Mandating its presence for C-SID does not resolve any problem because it will not provide any extra information to the nodes along the

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

On Thu, Mar 28, 2024 at 8:40 AM Robert Raszuk wrote: > > Hi Tom, > > Not really. > > RFC8200 defines an exception which is tunneling and says: > > As an exception to the default behavior, protocols that use UDP > as a tunnel encapsulation may enable zero-checksum mode for a >

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

Hi Tom, Not really. RFC8200 defines an exception which is tunneling and says: As an exception to the default behavior, protocols that use UDP as a tunnel encapsulation may enable zero-checksum mode for a specific port (or set of ports) for sending and/or receiving.

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

On Thu, Mar 28, 2024 at 7:46 AM Robert Raszuk wrote: > > Hi Tom, > > > because of SRH > > Ok I buy this that there are devices which do check checksum and are not > final destination of the packets ... I was more talking about plain > forwarding devices (aka P routers). Then I doubt firewalls

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

Hi Tom, > because of SRH Ok I buy this that there are devices which do check checksum and are not final destination of the packets ... I was more talking about plain forwarding devices (aka P routers). Then I doubt firewalls would be sitting in the core of the networks. But let me come black

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

On Thu, Mar 28, 2024 at 6:26 AM Robert Raszuk wrote: > > Hi Alvaro, > > On this specific topic I think you have flatted it a bit too much. > > These are apparently the options on the table: > > A) Original packet get's encapsulated with IPv6 header > > A.1 SHR is added to it > >

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

Hi Alvaro, On this specific topic I think you have flatted it a bit too much. These are apparently the options on the table: A) Original packet get's encapsulated with IPv6 header A.1 SHR is added to it A.1.1. Regular SIDs are used A.1.2 Compresses SIDs are