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

[Alexandre Petrescu <[e-mail]>]

Le 19/12/2019 à 19:55, Tom Herbert a écrit :
> 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.

But in that case (dont change src and dst addresses, just insert 
headers) then the packet would not pass through other enforced 
intermediary destinations before reaching the final destination.

In such a case, there could be headers inserted but the contents in 
these headers would not be IP addresses of intermediaries, but some 
other applicatioin-layer data.

If so, why would not be these data added as a payload, and not as an IP 
extension header?  I.e... encapsulate?

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

I agree.  It depends what is measured, and how the routing is realized.

Some routing might put bigger packets on a different path, just because 
of their size.  This mechanism would be fooled by someone inserting 
headers because it created bigger packets.

Other routing might work hand-in-hand with the header insertion 
mechanism (in same computer the process deciding a path be same process 
inserting headers).

To my mind it comes down again to the concept of a limited domain: if in 
a limited domain the routing and header inserters are bound closely, and 
ends of the comm are both there, then it migh work.

It might be that measurement mechanisms you mentioned, and ECMP 
(multi-path routing), and header insertion, might be appropriate in a 
limited domain.

Alex

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