On 4/2/2015 7:49 AM, Templin, Fred L wrote:
> Hi David,
>
>>> This is where we differ - there is nothing in this recommendation
>>> that is specific to GRE - the recommendation applies to any generic
>>> IPv6 encapsulation and is appropriate to only those use cases where
>>> shutting down the tunnel altogether is preferable to allowing the
>>> tunnel to fragment. This is a generic IPv6 encapsulation consideration;
>>> not a GRE consideration.
>>
>> The "running code" involved here is GRE. I am concerned that we lack
>> the foundation to update 2473 for all encapsulated protocols.
>
> I don't get that. Just write a 3-pager that says it is OK for any kind of
> tunnel to collapse if it gets into a state where fragmentation is needed;
> a halt-and-catch-fire clause. But, why would you even need an RFC for that?
For the benefit of others, here's my view on this (as I posted to Fred
yesterday, which is where collapsing the tunnel comes from):
defs:
ingress packet - what arrives at the tunnel ingress
egress packet - what leaves at the tunnel egress
tunnel packet - packet that traverses from the
ingress to egress, that contains
the ingress packet plus encapsulation
tunnel MTU - MTU of the path between ingress and egress
of tunneled packets
reassembly MTU - largest tunnel packet that can be
reassembled at the egress
General rules (which apply to more than GRE; they should apply to ANY
tunnel that carries ANY packet):
ingress packet <= (tunnel MTU - encapsulation)
send through the tunnel as one tunnel packet
ingress packet > (reassembly MTU - encapsulation)
drop and send ICMP PTB back
(tunnel MTU - encaps) < ingress packet <= (reassy MTU - encaps)
do one of the following:
a) fragment at ingress and reassemble at egress
b) drop and declare the link down to all further
traffic until a probe of size "reassy MTU"
succeeds to the egress
(this is what Fred just called "halt and catch fire",
but it has an important property:
- stay down while the required tunnel MTU
cannot traverse without fragmentation
- come up when the required tunnel MTU
is supported)
(a) is more robust but more expensive to implement
The tunnel MTU is defined by the protocols over which the tunnel is
defined as transiting.
The egress MTU is defined by the encapsulation protocol.
Note: the (b) case is allowed because a link can always declare itself
down. What it should never do is fail to transit packets that should fit
while allowing other smaller packets to get through - i.e., a link
should never be allowed to redefine the specs of the type of protocol
link it intends to support.
The rules are augmented a bit when the ingress packet can be re-fragmented:
ingress packet <= (tunnel MTU - encapsulation)
send through the tunnel as one tunnel packet
ingress packet > (reassembly MTU - encapsulation)
refragment the ingress packet to fit the tunnel MTU
(tunnel MTU - encaps) < ingress packet <= (reassy MTU - encaps)
do one of the following:
a) fragment at ingress and reassemble at egress
b) refragment the ingress packet to fit the tunnel MTU
in this case, (b) is preferred
---
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
