> On Mar 22, 2021, at 1:33 PM, Vasilenko Eduard <[email protected]>
> wrote:
>
> Hi Joseph,
> You insist that the second MTU restriction exists for all data plane
> implementations, just it is not visible and not discussed: neither in any RFC
> nor in any vendor documentation.
No; it is DEFINED in RFC1122 and noted in both RFC791 and RFC2460 (and 8200).
It’s exactly the difference between what can be sent on a path and what is
reassembled at an endpoint. Ingress are sources and egresses are sinks; host
requirements apply to BOTH.
> But then should be the same effect: fragmentation between MTUs.
They do not.
> I am sure that it is not the case.
> PTB would decrease the only MTU that tunnel has,
> The next oversized packet would get PTB message in the direction of the host.
>
> The buffer is not relevant for the discussion because data plane firmware
> just does not have a second MTU. This restriction just does not exist in the
> real life on the planet Earth.
PTB inside a tunnel needs to update the ingress to change fragment size,
because it says “the tunnel path can’t handle the packet size being relayed”,
but the path CAN handle the packet if the ingress adjusts. That’s why it is
INCORRECT to relay that info to the origin source - PTB inside the tunnel does
not mean the tunnel has failed, but rather that it needs to be adjusted.
When the egress cannot reassemble a packet because it is too large, it should
send some sort of error back - such as EMTU_R exceeded, but *there is no such
ICMP error*. However, IF THERE WERE such a message, then THAT message inside
the tunnel should generate a PTB to the origin host. That’s because if you
exceed EMTU_R of the tunnel egress, then the source has to send smaller packets
- there’s no other way.
In a nutshell, THAT IS WHY THEY ARE DIFFERENT:
- PTB inside the tunnel means “I’d PREFER a different size, but can
still live with this size”
it cannot be relayed to the origin because there is no meaning
that indicates PREFERENCE - only strict capability
- EMTU_R exceeded inside the tunnel means “I cannot accommodate this
size at all”
which WOULD need to be relayed to the origin source as PTB
The ultimate problem here is that:
- there aren’t the right ICMP messages to do this correctly
- there’s no point in creating new ICMP messages to fix the issue,
given ICMPs are generally blocked
Joe_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
