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

[Tom Herbert <[e-mail]>]

On Thu, Dec 19, 2019 at 5:05 AM Alexandre Petrescu
<[e-mail]> wrote:
>
>
>
> Le 18/12/2019 à 23:07, Tom Herbert a écrit :
> > 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.
>
> Why would ECMP (Equal-cost multi-path routing) be influenced by an
> addition of an IP header (IPIP encapsulation) but not influenced by the
> insertion of an extension header?
>
Alexandre,

When IP encapsulation is performed, unless the outer destination
happens to be the same as the inner destination, the destination
address will be different and hence packet can be routed over a
different path even with just simple destination based routing. The
outer source address will also presumably be different, so even if the
destination address were the same, the ECMP hash computed as routers
would still be different so packets could take a different path.

With extension header insertion, the IP addresses are not changed.
Neither is the flow label, nor any transport ports. So the network
still routes to the same destination address, and if ECMP is in use
the same hash is always produced since the inputs to the hash remain
the same after the header insertion.

> > Extension header insertion would maintain the routing in ECMP
> > (although the fact that extension headers aren't supported in IPv4
> > creates another problem).
>
> ECMP distinguishes between IP headers being extension headers vs base
> headers?  IF yes, it should be modified to work with base headers
> addition as well (encapsulation IPIP).

Some implementations might do that, but not all. In IPv6 this is
unnecessary since the flow label contains per flow information so
routers don't need to parse beyond the IPv6 header to do EMCP. Also,
packets must be routed based on (outer) destination address, ECMP is
only used to pick amongst possible paths to a destination. Even if the
EMCP hash computation is the same, the packets might still follow
different paths when destination address is different.

>
> > 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!
>
> Inserting data in the packets and then measuring them - isn't it an
> interference with the phenomenon to be measured?
>
Yes, there certainly is some uncertainty principle effects, however I
imagine  not measuring the "actual" path for a flow would probably be
considered as invalid results.

Tom

> Alex
>
> >
> > 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
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list [e-mail] Administrative
> > Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------