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

Joe Touch <touch@isi.edu> Tue, 16 May 2017 23:40 UTC

Return-Path: <touch@isi.edu>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B26712ECB8 for <int-area@ietfa.amsl.com>; Tue, 16 May 2017 16:40:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXC1GxsLcZTD for <int-area@ietfa.amsl.com>; Tue, 16 May 2017 16:40:23 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8F712EAF6 for <int-area@ietf.org>; Tue, 16 May 2017 16:36:45 -0700 (PDT)
Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4GNaUlU002793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 16 May 2017 16:36:30 -0700 (PDT)
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
Cc: "int-area@ietf.org" <int-area@ietf.org>
References: <149062888196.30638.8369941985115982808@ietfa.amsl.com> <f5ab0422-fd49-9082-147b-8312e974de7e@isi.edu> <4d2a86f4948c4dc49ab3b0729743d028@XCH15-06-08.nw.nos.boeing.com> <6573ad04-a1a6-3f2c-8470-c2babaf36110@isi.edu> <68f2a2ff5e6647f3837be0c2811120ee@XCH15-06-08.nw.nos.boeing.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <aec44d02-649d-d103-ae6f-e2390689324e@isi.edu>
Date: Tue, 16 May 2017 16:36:30 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0
MIME-Version: 1.0
In-Reply-To: <68f2a2ff5e6647f3837be0c2811120ee@XCH15-06-08.nw.nos.boeing.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/hgCisxrjod2ad1U7WSQWeibMezw>
Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 May 2017 23:40:24 -0000

HI, Fred,

AOK - I can add that. The point is that *IF* you get multiple answers
(regardless of how), you use the min.

And the ingress needs to determine that value before sending for sure
and there's always the possibility of PMTUD doing odd things if ICMPs
are blackholed here - but partial delivery in that case isn't unique to
tunnels.

I'll mention it, though.

joe


On 5/16/2017 4:31 PM, Templin, Fred L wrote:
> Joe,
>
>> -----Original Message-----
>> From: Joe Touch [mailto:touch@isi.edu]
>> Sent: Tuesday, May 16, 2017 4:17 PM
>> To: Templin, Fred L <Fred.L.Templin@boeing.com>
>> Cc: int-area@ietf.org
>> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
>>
>> Fred,
>>
>> Regarding the following point:
>>
>>
>> On 3/28/2017 9:36 AM, Templin, Fred L wrote:
>>> 19) Section 4.3.3, third paragraph, I thought it was said earlier
>>>     that all ingress/egress pairs must support the same MTU. I
>>>     thought we agreed earlier on that that multi-MTU subnets
>>>     don't work. So, I think it should say that all ingress pairs
>>>     MUST support a uniform MTU.
>> The cited section allows for ingress/egress pairs that don't support the
>> same MTU, but then says that the MTU used for that set is the minimum of
>> those MTUs.
>>
>> There's no way (short of configuration management) to ensure that
>> ingress/egress pairs MUST support the same MTU, but no real value to
>> requiring that - AFAICT, we just use the min across that set (which is
>> what that section says to do).
> What I am trying to get at is the need for an ingress to determine the
> minimum before it sends a packet that may be too big for one of the
> multipoint link egresses. On IPv6 links, this could be through receipt
> of an MTU option in a Router Advertisement message. Other ways
> are possible (e.g., static configuration) but there needs to be some
> way for all ingresses to determine the minimum.
>
> Thanks - Fred
>
>> So yes, we do not *use* different MTUs per-destination, but we don't
>> need to require it AFAICT.
>>
>> Joe