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
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
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
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
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
>
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
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
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
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
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,
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.
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
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:
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
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
>
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
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
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
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
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
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,
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
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
>
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
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
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
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
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
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
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
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
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
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
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
>
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
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
>
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.
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
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
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
>
>
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
41 matches
Mail list logo