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

"Templin, Fred L" <> Wed, 03 May 2017 21:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 18DA7129B34 for <>; Wed, 3 May 2017 14:26:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6Zp71Pg-d1vd for <>; Wed, 3 May 2017 14:26:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7BA2E129B4F for <>; Wed, 3 May 2017 14:24:50 -0700 (PDT)
Received: from localhost (localhost []) by (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v43LOnXM015603; Wed, 3 May 2017 14:24:50 -0700
Received: from ( []) by (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v43LOdSS015537 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 3 May 2017 14:24:39 -0700
Received: from (2002:8988:eede::8988:eede) by (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 3 May 2017 14:24:38 -0700
Received: from ([]) by ([]) with mapi id 15.00.1263.000; Wed, 3 May 2017 14:24:38 -0700
From: "Templin, Fred L" <>
To: Joe Touch <>
CC: "" <>
Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
Thread-Index: AQHSpxB0dZTEVAB270esoqM4xp8NZaGqcslggACqEoCAASy6sIAAjvoAgDY8cKCAAI2TgP//mgIggACFEQD//4vQgA==
Date: Wed, 3 May 2017 21:24:38 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <>
Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 May 2017 21:26:26 -0000

Hi Joe,

> -----Original Message-----
> From: Joe Touch []
> Sent: Wednesday, May 03, 2017 1:38 PM
> To: Templin, Fred L <>
> Cc:
> 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 []
> >> Sent: Wednesday, May 03, 2017 11:47 AM
> >> To: Templin, Fred L <>
> >> Cc:
> >> 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.


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


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

> Joe