Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

[Tom Herbert <[e-mail]>]

On Thu, Sep 5, 2019 at 12:20 PM Robert Raszuk <[e-mail]> wrote:
>
> Hi Tom,
>
>>
>> insertion. For instance, I'd invite you do the thought experiment
>> about what happens when an intermediate node inserts a header that
>> causes the packet to exceed the MTU of some downstream forwarding
>> node.
>
>
> Absolutely.
>
> But SRH is meaningful only within a given domain.
>
Robert,

I don't see how that's relevant. The fact that a protocol is
_intended_ to be used only in a controlled domain is hardly a
substitute for doing the work to make the protocol robust. I don't
subscribe to the idea that just because a protocol runs in a limited
domain all of the problems magically go away.

> At least I would worry much less about MTU being exceeded when you insert EH as compared when you encapsulate with complete new header including EH, DO etc ... which somehow everyone seems to be happy about. I am not seeing much logic here.
>
Because, when a node encapsulates a packet it places _its_ address in
the source address field. This provides the necessary attribution. So
when the encapsulated packet causes issues it is clear who the culprit
is-- they receive the ICMP error or when the packet is error is logged
it's clear who created it. Attribution is critical to correct network
operation.

> Moreover if you look at telco transport today a lot of "circuits" are emulated circuits which use encap in the middle of the transports which in turn runs over their IP networks. How do you deal with such cases when one day it works and when telco underly reroutes such that it goes via bottleneck it does not ?
>
That's a deployment problem, not a protocol problem. That should be
taken up in IPv6 ops WG I would think.

> I am seeing this daily. We even wrote IETF drafts to detect this. Now the BFD draft stuffing is a third attempt to have a tool to detect it. If IPv6 works end to end, hosts to hosts such MTU bottleneck should be part of the IPv6 transport.
>
>> There is no robust protocol mechanism to deal with this.
>
>
> That's a problem much bigger then SR. See when I am building transport over third parties I use SLA probes which periodically validates not only SLA data but also end to end max MTU. When I see an issue I choose automatically different underlay path such that end applications do not notice the issue.

Right, anytime an intermediate node materially changes a packet
outside of the standard protocol or increases the size of packet they
are risking end to end robustness and reliability. That's why RFC8200
precludes EH insertion, and why other similar proposals to make
non-standard modifications to packets in flight will be met with
resistance in IETF.

Tom

> Many thx,
> R.
>
>>