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
