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

[Alexandre Petrescu <[e-mail]>]

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?

> 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 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?

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 
> --------------------------------------------------------------------
>