Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Friday, June 17, 2016 2:47 PM > To: Templin, Fred L <[email protected]>; Vincent Roca > <[email protected]> > Cc: [email protected]; [email protected] > Subject: Re: [Int-area] Comments for draft-ietf-intarea-tunnels-02 > > > > 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)
The problem is that the ingress is not the source of the original packets; it is only the source of the tunneled packets. And, the ingress may need to encapsulate packets coming from many original sources that may have many different flow label and/or TOS values. Therefore, there is no way for the ingress to ensure that any probes it sends will travel over the same paths that ordinary data packets will travel due to multipath. This means that the ingress cannot consider receipt of a probe reply as conclusive evidence that all paths in the multipath can deliver packets as large as the probe packet. Otherwise, the tunnel could be working for some data packets but silently black-holing other data packets. This is why the tunnel ingress cannot employ RFC4821-style MTU probing. Thanks - Fred [email protected] > Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
