On 6/17/2016 2:28 PM, Templin, Fred L wrote: >>> It is true that one possibility is for the tunnel to simply shut down if it >>> > > encounters an MTU underrun meaning that one or more destinations >>> > > will simply become unreachable. But, that sort of arrangement may not >>> > > be acceptable for safety-critical communications where destinations >>> > > should be made reachable through any means available. >> > Yes - this is the only end-run that seems to work within the constraints >> > of existing specs. It does have a downside, though - it basically works >> > like "the tree in the forest". Until it actually falls, there's no point >> > in preventing its use. However, once it falls, it cannot get "back up" >> > again - if it did, it would act like a link that requires a different MTU. >> > >> > So it's "optimistic" with a fairly bad failure mode. IMO, its' the only >> > safe way to deploy non-reassembling tunnels, even in a "controlled" >> > environment -- because "controlled" is only true as long as it can be >> > known, and the "shut-down" approach serves a a monitor to enforce that >> > control. > As an eternal optimist, that kind of failure mode really bums me out. We > definitely can't use it for airplane comms where we have to ensure safety > of flight even over data links that have sub-Mbps throughput and hence > fragmentation may be the only option. But, I guess in other environments > if you hit the MTU wall there is no choice but to go belly-up... My view is that it's much better than just "assume the network has been engineered properly", largely because all networks may ultimately be re-deployed over tunnels unknowingly. Better to detect the failure to support the required MTU than to ignore it.
(yes, I'd be even happier if all networks periodically tested the minimum MTU as part of operations monitoring) Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
