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
