[spring] 6MAN Chairs conclusions on Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

[Bob Hinden <[e-mail]>]

Alvaro, Spring Chairs,

The 6MAN chairs have reviewed the discussion on your query to the IPv6 list.   This is our thoughts.

Process wise we don’t think we can declare any kind of formal consensus on this.   We are sure you have also read the discussion.  We do have some feedback from our reading of the discussion.  

Our read is there is a number of people who don’t like using C-SIDs due to issues relating to verify transport checksums due to not having access to final destination address.   We don’t think this is a significant issue as long as they are in a SRH header.  That provides additional context that C-SIDs may be in use.  

We think there is a stronger issue when using C-SIDs without a SRH header.   There isn’t any context for knowing how to handle these packets.   We also agree with the point was that for an endpoint, there would be no way for that endpoint to do hardware offload for the TCP checksum.  Even if the NIC supported SRH it would not know how to restore the original destination address.  These NICs commonly fail to do TCP offload with any routing header or other extension headers too, so the failure is there.  It is made worse without having any context that C-SIDs are being used.

We think this issue could be reduced if there was a way to identify that the packets contained C-SIDs.  For example, if they were using the prefix defined in <draft-ietf-6man-sids>.  We note that <draft-ietf-spring-srv6-srh-compression> does reference this prefix defined in <draft-ietf-6man-sids>, but does not require its use.

Bob, Ole, Jen