Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt

["Templin, Fred L" <[e-mail]>]

Hi Joe,

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Wednesday, May 03, 2017 1:38 PM
> To: Templin, Fred L <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
> 
> HI, Fred,
> 
> On 5/3/2017 1:07 PM, Templin, Fred L wrote:
> > Hi Joe,
> >
> >> -----Original Message-----
> >> From: Joe Touch [mailto:[e-mail]]
> >> Sent: Wednesday, May 03, 2017 11:47 AM
> >> To: Templin, Fred L <[e-mail]>
> >> Cc: [e-mail]
> >> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
> >>
> >> Hi, Fred,
> >>
> >> Your response keeps raising the same issues that I think we agree upon:
> >>
> >>     - PMTUD always has the possibility of creating black holes (whether
> >> in the presence of multipath or not)
> >>
> >>     - PLPMTUD can generate cases where the MIN isn't actually detected
> >>
> >> and some claims with which I disagree:
> >>
> >>     - that PMPMTUD probes travel different paths than the data
> > I think I have already said this many times, but let me try again. The
> > tunnel ingress is not the source of the transit packet; it is only the
> > source of the tunnel packet. And, the ingress may have to tunnel
> > a wide variety of transit packets sourced by many original sources.
> > So, if ECMP somewhere within the tunnel peeks at the transit
> > packet, then the packet could take a very different path within
> > the tunnel than the ingress' PLPMTUD probes took.
> OK, so we have to separate things out.
> 
> PLPMTUD E2E will still work fine - or not - and isn't affected by the
> presence of a tunnel per se.

Agreed - E2E from transit packet source to transit packet destination is
not affected by the presence of the tunnel.
 
> The same is true for PMTUD E2E.

OK.

> The issue is how the  tunnel itself figures out MTU values larger than
> the required minimums for transit to the egress. There are two cases:
>     - for egress reassembly, a tunnel protocol can communicate that
> reassembly MTU explicitly (and the MIN taken for multipoint tunnels, as
> with multicast)

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.

>     - for transit between ingress and egress, the tunnel would need to
> either use PMTUD (and be susceptible to black holes)

Yes.

> 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.

>             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.

> >> Those probes should be used to determine an MTU only for a
> >> given flow; the potential hazards of sharing that information across
> >> flows is already discussed in that RFC.
> > I don't think RFC4821 does enough to take ECMP into account when it
> > talks about storing and sharing discovered MTUs.
> While I agree, this document is not intended to update that nor to
> account for its deficiencies, so I'm not sure what to add other than as
> stated above.

Agreed, this is an RFC4821 issue and potentially subject for an erratum
for that document (not this one).

> ...
> >
> >> 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?

> > ...
> > 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.

Thanks - Fred
[e-mail]

> Joe