Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt

[Tom Herbert <[e-mail]>]

On Fri, Dec 1, 2017 at 11:15 PM, Stefano Salsano
<[e-mail]> wrote:
> Il 2017-12-01 23:07, Mark Smith ha scritto:
>
> <snip>
>>
>>
>> I asked numerous times (at least 3 from memory), what is wrong with
>> exclusively using tunnelling for this. I think eventually Robert said
>> because of the tunnelling overhead.
>>
>> The trouble with this argument is that this draft doesn't exclusively
>> propose extension header insertion, it also describes using
>> tunnelling. The only distinction between which method to use is
>> whether the packet originates within the SR domain ("Source Domain and
>> Packet Journey") or originates externally to it ("Transit through a
>> Source Domain"). So tunnelling overhead is apparently quite acceptable
>> as long packets happen to come from outside the SR domain. I can't see
>> anything that explains why packets that originate internally can't or
>> must not be tunnelled.
>
>
> Hi Mark,
>
> with the first tunneling operation you create a new packet that originates
> in your SR domain.
>
> We definitely want it, so the further SR insertion will only be applied to
> such packets (and hosts outside the domain will not receive unexpected
> ICMP...) and we believe that it is worth paying the tunneling overhead here.
>
Stefano,

The problem is that almost all hosts are outside of the SR domain,
even ones attached to the local network. If hosts were within the SR
domain they could just source packets with the right extension headers
or encapsulation. But that is not common, especially in a public
network. So it seems likely nearly all packets would end up being
encpasulated anyway (i.e. the packet flow in section 3 will be
common).

If packets are tunneled when they enter the domain then that should
provide sufficient isolation so that the encapsulating node can use
whatever extension headers it wants (e.g. tunneling should ensure that
source hosts won't receive unexpected ICMP). But then that's not EH
insertion, that is sourcing a packet with EH in compliance with
RFC8200. The only argument for EH insertion then would be if some
intermediate node in the domain inserted something; this at least only
affects packets sourced within the domain so information is less
likely to leak out of the domain. However, in that case why not do the
segment routing at the ingress node of the domain in conjuction with
the encapsulation and avoid the complexities needed to make EH
insertion work correctly?

> We think that for further operations that require adding of SRH information
> to such packets originating in your SR domain, the SR insertion is more
> efficient than tunnelling into a new packet.
>
> This is both from the point of view of the packet size (and increase of
> packet headers size) and from the point of view of the cost of packet
> manipulation operations.
>
Packet manipulation operations where? At an intermediate node
processing is more likely to take a performance hit because of the
presence of extension headers regardles of whether they were inserted
directly or in an encapsulation,

An assumption that more bits in the packet always reduces efficiency
would be incorrect. For instance, we have shown on real hardware that
GRE/UDP/IP is more efficient than GRE/IP. This is because network
devices have optimized for processing UDP/IP as opposed to GRE/IP so
the benefits of additional eight bytes UDP header outweighs the cost.

A performance analysis based on empirical data should be in the draft
if efficiency of packet manipulation is a primary motivation.

> There can be scenarios in which you have more than one such operation to be
> applied to the packet, let us assume two. If you go for tunnelling you have
> the first encapsulation, then two more IPv6-in-IPv6 encapsulation in the
> same packet, for a total of 3 encapsulations. If you go for tunneling + SR
> insertion you only have the first encapsulation and then "simple" mangling
> of SRH header.
>
I understand how nested encapsulation could work to cross multiple
domains, I don't see how this would be done with SR insertion. Maybe
the intent is that packets will have a stack of routing headers?
Please elaborate this use case in the draft.

Tom