Re: What is necessity for SRH, and other EH, insertion/removal?

[Tom Herbert <[e-mail]>]

On Sat, Dec 7, 2019 at 9:17 AM Tom Herbert <[e-mail]> wrote:
>
> Pulling this out into a separate thread. Pertinent questions are:
>
> Why is extension header insertion and removal at necessary?
>
> Why isn't the proposed alternative of IPIP encapsulation sufficient?
> (where the encapsulating headers contain the extension headers that
> would otherwise be inserted)
>
I believe that inband network telemetry (INT and IOAM ) might provide
the best motivation for extension header insertion. One of the goals
is to allow network operators to perform telemetry on packets as they
traverse their network. A telemetry header, INT or IOAM, is put into
packets on ingress to the domain and removed at egress, and
intermediate nodes modify the packet with measurement data.

Key requirements are that not all packets for a flow need to be
measured, and measured packets need to follow the same path as those
not measured  in order for the measurements to reflect what is
happening for the flow. IPIP encapsulation would change the hash that
ECMP uses so encapsulated packets might traverse a different path--
therefore it's not sufficient in this case. Extension header insertion
would maintain the routing in ECMP (although the fact that extension
headers aren't supported in IPv4 creates another problem).

Some of the inband telemetry implementations are already addressing
this by inserting the inband telemetry headers directly into the UDP
or TCP payload of existing packets and removing the inserted payload
bytes at the egress point. Since only transport payload is being
modified, the packets will be routed the same way as other modified
packets for a flow. The obvious problem with this approach is that
payload is being changed by intermediate nodes such that if the end
host were to ever receive the modified packet this could result in
silent data corruption of users' data. So this protocol mechanism is
fundamentally not robust and probably dangerous. I think this actually
makes extension header insertion, where the worst case scenario is
probably unexplained packet loss, look palatable!

Tom

> Please note, I'm asking for the technical justification of the
> protocol design, saying that it's necessary because it's already being
> deployed isn't useful in this regard.
>
> Tom