Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Wednesday, May 03, 2017 2:38 PM > To: Templin, Fred L <[email protected]> > Cc: [email protected] > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt > > Winnowing down... I think we're converging. Let me know if not... > > Joe > > > On 5/3/2017 2:24 PM, Templin, Fred L wrote: > > ... > > I thought for multipoint tunnels all egress' had to have the same reassembly > > MTU? Or, if taking the minimum, that minimum value could be conveyed in > > the MTU option in a Router Advertisement message. > The egresses could theoretically convey different reassembly MTUs, but > the ingress would take the min. If you have a control protocol that has > all the information, you can push that operation there.
Sounds OK. > >> or PLPMTUD > >> - if it uses PLPMTUD, then steps need to be taken to either > >> establish the ingress-egress as a single flow (so that ECMP would treat > >> it as such) or to somehow try to manage subsets of arriving flows as a > >> single flow > > The "pipe model", yes. The only problem is that an ECMP device could still > > do deep-packet inspection and make multipath decisions based on the > > transit packet. > See next response... > >> and any such method needs to be careful to ensure that the > >> probe packets are not distinguishable from non-probes, or could create > >> false information > >> > >> Would that be sufficient? > > I think some would still say that an ECMP device that does deep packet > > inspection could still trigger multipath based on the transit packet. > > I think I already cover that in saying "not distinguishable" (e.g., > either by encryption or mimicry) Encryption for sure, yes. But, I'm not sure about mimicry. > > > >> ... > >>>> I don't yet see any explanation as to why this would be true. > >>>> > >>>> So I'm left with the following, which I propose as the way forward: > >>>> > >>>> - the text will be clear about the potential issues for multipath > >>>> potentially taking a long time to converge > >>> It's not that it could take a long time to converge - it is that it might > >>> never converge if some paths of the multipath block ICMPs. > >> If the path can't differentiate data and probes (see above), I can't see > >> how they can be prevented from converging. > > If the transit packet is visible in-the-clear, then some deep-packet > > inspecting ECMP device could still invoke multipath. But, it just occurred > > to me that if the transit packet is encrypted then ECMP devices would > > only see the tunnel packet headers and not the transit. So, maybe the > > tunnel can implement the RFC4821 pipe model for IPsec/TLS? > Encryption is one approach. Right. > Some sort of mimicry is another - e.g., if > the ingress encapsulation includes both net and transport, with ports > assigned per "flow group" (such that a single incoming flow belongs to > only one tunneled flow). I think this depends on how deep the ECMP device could inspect. If it goes past all of the tunnel headers and inspects the transit packet then ECMP problems can occur. > >>> ... > >>> The tunnel ingress is only the source of the tunnel packets; it is not the > >>> source of the transit packets. The only way for PLPMTUD to function > >>> properly in the presence of ECMP would be for the source of the transit > >>> packets to do the RFC4821 probing - not the tunnel ingress. > >> Agreed - the only reason the ingress would want to do PLPMTUD probing is > >> to increase the size of the chunks sent to the egress. > > I think it still would have problems. For instance, if it discovered that a > > 1400byte chunk could fit over one path in the multipath, another path > > could be constrained to only 1399 bytes and ECMP could bite you again. > If that happens, PLPMTUD would learn it and adapt. Either enough packets > would get through or the ingress would adapt. The problem is that if there are N paths in the multipath the ingress has no way of knowing that it has probed all N of them. And, if a transit packet arrives that would be tunneled over a path that has not been probed, it could black hole if the MTU is too small. Thanks - Fred [email protected] > Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
