On Thu, Sep 5, 2019 at 12:20 PM Robert Raszuk <rras...@gmail.com> 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. > >> _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
