On 5/29/2013 1:06 PM, Linda Dunbar wrote:
Ron,
I do have a few questions and suggestion about the practices documented in the
draft:
- Section 4.1, second paragraph:
why DF bit "MUST" set to 1 when the payload header has "0"? I would think default should
be same as the "payload" DF setting.
DF in a tunnel header should be set to match the capability of that
tunnel mechanism. Either the tunnel wants to find the MTU and match it
or not; in the former case, it has to set DF=1 all the time.
For this doc, whether to set or copy the DF bit depends on whether PMTUD
is supported on a given tunnel. If it is (whether PMTUD or PLMTUD), then
set DF; otherwise, I agree - copy DF.
- Section 5.1, last sentence: "The GRE egree router will forward the
payload fragments to their ultimate destination where there will be
reassembled"
The GRE egress router should reassemble the fragmented payloads
before sending to the destination. In general, the network outside
the Egress router should be same as the network before entering the
Ingress router. If the data frame size is less than then MTU of the
network before entering the Ingress router, the decapsulated frame
size should be less than the MTU of the network outside the Egress
router.
I agree; my general recommendation has always been "the egress should
always clean up any mess created by an ingress" - which means using
"outer" fragmentation rather than "inner".
Yes, this can cause repeated frag/reassembly, but the alternative is to
shift work to the end host, which I think is inappropriate. Further,
this sort of clean-up is required by IPv6 and for IPv4 when when DF=1 on
the inner packet anyway.
In addition, it is the Ingress node split the frame, the final
destination may not be aware of how to reassemble the data frame.
This is a spurious point; the information is there if the inner packet
was fragmentable.
- There should be two options when the encapsulated data frame
exceeds MTU: a) split the data frame to two smaller frames, with each
frame being encapsulated; b) truncate the frame if the Egress node
needs to receive the data frame but doesn't have the capability to
reassemble split frames.
There are two viable options:
- fragment and reassemble (same as your option "a)" above)
- drop the packet (and presumably send a signal upstream)
Sending a truncated frame serves no useful purpose.
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
