So you can't ping a uSID list by just specifying the uSID as the
DA?Yours,JoelSent via the Samsung Galaxy S20 FE 5G, an AT&T 5G smartphone
-------- Original message --------From: Francois Clad <fclad.i...@gmail.com>
Date: 4/4/24 1:10 PM (GMT-05:00) To: Joel Halpern
<jmh.dir...@joelhalpern.com> Cc: SPRING WG List <spring@ietf.org>, Robert
Raszuk <rob...@raszuk.net>, Andrew Alston - IETF <andrew-i...@liquid.tech>
Subject: Re: [spring] C-SIDs and upper layer checksums
(draft-ietf-spring-srv6-srh-compression)
Hi Joel,One can ping a SID of this document without a segment list by
simply running the ping command with that SID as an argument (2nd paragraph of
section 9.1).To ping a SID of this document via a SID list, one needs to
configure the originator node to impose that SID list, like any other SRv6 SID
list.Hope this helps.Cheers,Francois
On 4 Apr 2024 at 16:29:11, Joel Halpern <jmh.dir...@joelhalpern.com> wrote:
<No Hats>
It seems that the text you quote requires that the ping code or
kernel code know that the user has specified a uSID for the ping
DA. Maybe I am missing something, but it is not obvious to me
how that would be achieved? And does seem to imply that an
unmodified ping will get incompatible and unexpected results?
Yours,
Joel
On 4/4/2024 10:23 AM, Francois Clad
wrote:
Hi Joel,
The ping behavior is described in section 9.1 of
the draft
(https://www.ietf.org/archive/id/draft-ietf-spring-srv6-srh-compression-14.html#section-9.1).
Specifically,
"When pinging a SID of this document via a segment
list, the SR source node MUST construct the IPv6 packet as
described in Section 6 and compute the ICMPv6 checksum as
described in Section 6.5."
Please let me know if anything in this text is not
clear.
Thanks,
Francois
On 4 Apr 2024 at 16:10:11,
Joel Halpern <jmh.dir...@joelhalpern.com>
wrote:
<No Hat>
Does this mean that if I have a source and destiantion
host inside an SRv6 domain, and I am trying to verify a
uSID path between them, so I issue the command ping
<usUD-DA>, it will fail? Given that we have
documents describing the use of ping and traceroute with
SRv6, shouldn't the comrpession document say someething
about this?
Your,s
Joel
On 4/4/2024 9:59 AM, Francois
Clad wrote:
Hi Andrew,
The originator (TX Linux box in your
case) acting as an SR source node for C-SID must
follow the entire Section 6 of
draft-ietf-spring-srv6-srh-compression, including
section 6.5 about the checksum calculation. One cannot
expect it to work if it only implements half of it.
On the receive side, there is nothing
special to do. The DA in the received IPv6 header is
the one that was used for the checksum calculation.
I do not see anything broken.
Cheers,
Francois
On 4 Apr 2024 at
15:32:12, Andrew Alston - IETF <andrew-i...@liquid.tech>
wrote:
So in
investgiating this further, there is a
further problem.
I’ve checked on 4
different linux boxes with 4 different
network cards.
Linux by default
offloads TX checksumming on a lot of
network cards. If you originate a packet
with a microsid and no SRH – and the linux
box offloads the checksum generation – the
checksum generated by the NIC will be
incorrect – and when the packet arrives at
the end host – if that end host is running
RX checksumming – the checksum will fail
and the packet will be dropped.
If you disable TX
checksumming – the kernel will have no way
to tell if the packet is an Ipv6 or a
microsid packet, it will therefore use the
DA – and generate an incorrect checksum.
Again – if RX checksumming is enabled on
the receiving end point – the packet will
get dropped.
Effectively this
does NOT just affect middle boxes – it
effects anything generating a packet
directed to a microsid that either
offloads the tx to hardware (whichi will
have no clue this is a microsid) or in the
alternative is generating tx checksums
itself via kernel mechanisms that will
treat these packets as standard Ipv6
packets.
This is broken –
severely broken.
Andrew
Internal All
Employees
From: spring
<spring-boun...@ietf.org>
on behalf of Francois Clad
<fclad.i...@gmail.com>
Date: Thursday, 4 April 2024
at 14:49
To: Joel Halpern <jmh.dir...@joelhalpern.com>
Cc: SPRING WG List <spring@ietf.org>,
Robert Raszuk <rob...@raszuk.net>
Subject: Re: [spring] C-SIDs
and upper layer checksums
(draft-ietf-spring-srv6-srh-compression)
Some
people who received this
message don't often get
email from fclad.i...@gmail.com.
Learn
why this is important
CAUTION: This
email has originated from a free
email service commonly used for
personal email services, please be
guided accordingly especially if
this email is asking to click
links or share information.
Hi all,
Section 6.5
of
draft-ietf-spring-srv6-srh-compression
specifies how an SR source node
originating a packet with an
upper layer checksum determines
the Destination Address for use
in the IPv6 pseudo-header.
As a
co-author, I’d say that the
current text of 6.5 is good.
This text is
aligned with RFC 8200. It only
indicates how the text in
Section 8.1 of RFC 8200 applies
to the SIDs of
draft-ietf-spring-srv6-srh-compression.
This is necessary since RFC 8200
does not specify the format nor
behavior of any source routing
scheme.
Thanks,
Francois
On 4 Apr 2024
at 00:10:55, Joel Halpern
<jmh.dir...@joelhalpern.com>
wrote:
I can not speak to the
"norm" for other working
groups. The SPRING charter
is very specific about what
we have to do if we want to
change an underlying
protocol. We have to go
back to the WG which owns
that protocol.
6man gets to decide if the
change is acceptable, and if
it is acceptable how it is
to be represented. SPRINGs
job is to make sure we are
asking the question we
intend.
Yours,
Joel
On
4/3/2024 6:05 PM, Robert
Raszuk wrote:
Ok
Joel,
Thank
you for this
clarification.
To
me the actual spirit
of RFC8200 8.1 is to
say that it is ok to
compute the checksum
by the src such that
it comes out right at
the final
destination.
But
I guess we can have
different opinions
about that.
But
what I find
specifically
surprising here is
that it is a norm in
IETF to have new
specifications
defining protocol
extensions and their
behaviour and never go
back to the original
protocol RFC to check
if this is ok or not.
If that would not be a
normal process I bet
we would still be
using classful IPv4
routing all over the
place.
Regards,
Robert
On
Wed, Apr 3, 2024 at
11:28 PM Joel Halpern
<j...@joelhalpern.com> wrote:
The concern with
regard to the text
that the chairs are
asking about is not
about intermediate
nodes verifying the
checksum. The text
does not talk aabout
that, so we are not
asking about that.
But, the text in
8200 specifies how
the originating node
is to compute the
upper layer
checksum. It
doesn't say "do
whatever you need to
do to make the
destination come out
right". It provides
specific
instructions. Yes,
it is understandable
that those
instructions do not
cover the compressed
container cases.
Which is why the
compression document
specifies changes to
those procedures.
Thus, we need to
ask 6man how they
want to handle the
change in the
instructions in
8200.
the question we are
asking SPRING is
whether there is any
clarification people
want to the text in
the compression
draft before we send
the question over to
6man.
Yours,
Joel
On
4/3/2024 5:15 PM,
Robert Raszuk
wrote:
Hi Joel,
My interpretation of
text from RFC8200 is that it
allows
discrepancy
between the
header and the
upper layer
checksum as
long as final
packet's
destination
sees the
correct one.
The last condition is
met.
So I see no issue.
Sure RFC8200 does not
talk about SRH nor cSIDs, but
provides a
hint on how to
handle such
future
situations.
With that being said I
would like to still understand
what real
problem are we
hitting here
...
Kind regards,
Robert
On Wed, Apr 3, 2024
at 11:09 PM Joel Halpern
<j...@joelhalpern.com>
wrote:
There are
two cases
covered in
section 6.5 of
the
compression
draft that
appear to be
at variance
with secton
8.1 of RFC
8200.
First, if
the final
destination in
the routing
header is a
compressed
container,
then the
ultimate
destination
address will
not be the
same as the
final
destination
shown in the
routing
header.
Second, if
a uSID
container is
used as the
destination
address and no
SRH is
present, then
in addition to
the above
problem there
is no routing
header to
trigger the
behavior
described.
Yours,
Joel
On 4/3/2024 4:22 PM,
Robert Raszuk wrote:
Hi Alvaro,
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.
I would like you to
clarify the above statement -
specifically of
the last
sentence.
Reason for this that
after looking at both drafts I
find section
6.5 of the
subject draft
to be exactly
in line with
RFC8200
section 8.1
especially
with the
paragraf which
says:
If the IPv6
packet contains a Routing
header, the
Destination
Address used
in the
pseudo-header
is that of the
final
destination.
At the
originating
node, that
address will
be in
the
last element
of the Routing
header; at the
recipient(s),
that
address will
be in the
Destination
Address field
of the
IPv6
header.
So before we dive
into solutions (as Andrew has
already
provided a few
of) I think we
should first
agree on what
precise
problem are we
solving here ?
Many thx,
Robert
PS. As a side note I
spoke with my hardware folks -
just to check
if validation
of upper-layer
checksum is
even an option
for transit
nodes. The
answer is NO
as most data
plane hardware
can read at
most 256 bytes
of packets. So
unless there
is some
specialized
hardware
processing up
to 9K packets
in hardware at
line rates
this entire
discussion
about checksum
violations,
fears of
firing appeals
is just
smoke.
_______________________________________________
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
