Re: Path MTU Hop-by-Hop Option

"Rajiv Asati (rajiva)" <rajiva@cisco.com> Wed, 17 October 2018 12:14 UTC

Return-Path: <rajiva@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C24130DD3 for <ipv6@ietfa.amsl.com>; Wed, 17 Oct 2018 05:14:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.564
X-Spam-Level:
X-Spam-Status: No, score=-14.564 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 5HW1pPHm5R79 for <ipv6@ietfa.amsl.com>; Wed, 17 Oct 2018 05:14:33 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2AB7130DC1 for <ipv6@ietf.org>; Wed, 17 Oct 2018 05:14:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2684; q=dns/txt; s=iport; t=1539778473; x=1540988073; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JbUp5+g813/yWLBXRTdHh81kzudzxmnTXUCeca3xgkM=; b=Ttw7eJCNcXPau8E8PHhSi6TYPRiQFoAsAVu6H0t0yUO2IAtidEu/exUN RejIv92DJeBRtdlVKsx2Up/1IwgozD2nIZ6HUZnTafqQm+fEmncWv0KQx bMFdqd9Alugzt38QrT3eCHd6vcfAOkFZYY9PYHHtGSGdkHQb56i9CWPs9 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAABIJsdb/4QNJK1kGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBggRmfyiMDIwagWgllwwUgWYLAQEYC4RJAoR6ITQNDQEDAQECAQECbRwMhTkBAQEBAgEBATg0CxACAQgOChUJECcLJQIEDgUbgwUBgXkID6VLhDACgQiEWQWLTBeBQT+BEicME4JMgxsBAQOBGRIBEgEfP4J1giYCiGiVSQkChlaKCxeBT4RxgxSGToxIiUwCERSBJh04ZHFwFTsqAYJBgiYXiFuFPm+JTII+AQE
X-IronPort-AV: E=Sophos;i="5.54,392,1534809600"; d="scan'208";a="187315500"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Oct 2018 12:14:32 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id w9HCEWp7020010 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 17 Oct 2018 12:14:32 GMT
Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 17 Oct 2018 07:14:32 -0500
Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1395.000; Wed, 17 Oct 2018 07:14:32 -0500
From: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
CC: Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>
Subject: Re: Path MTU Hop-by-Hop Option
Thread-Topic: Path MTU Hop-by-Hop Option
Thread-Index: AQHUZaNyn0MzVSaXDkmqk/hdOPxGiKUjUmCAgAAIRIo=
Date: Wed, 17 Oct 2018 12:14:32 +0000
Message-ID: <CC0514D7-723A-426C-9326-3D02880B4C9E@cisco.com>
References: <153972960647.9465.12295361632444928551.idtracker@ietfa.amsl.com> <E97952C5-3E3C-4EC1-B414-BDA8717FD7DF@gmail.com>, <alpine.DEB.2.20.1810170838400.17344@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.2.20.1810170838400.17344@uplift.swm.pp.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: alln-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Af7u4_mkvJox4K_xe3CfBBgxaBM>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Oct 2018 12:14:36 -0000

Well put, Mikael. Both MTU and MRU are important for PMTU. And in case of incoming interface and outgoing interface of a router, those values can be different.  

And the assumption that two routers connected via a link will likely have the same IP MTU in a sane design is not always true. We have seen the non-compliance crop up time to time even in well managed networks. 

At minimum, it should be made clear what the host cares for and what the routed network reports - MTU vs IP MTU vs MPLS MTU. 

Having said all that, it is a bit puzzling to expect any network giving HBH option so much more tender and making this ICMP solution more efficient than the others. 

Cheers,
Rajiv  

>> On Oct 17, 2018, at 2:45 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
>> 
>> On Tue, 16 Oct 2018, Bob Hinden wrote:
>> 
>> Please read the draft.  Links below.
> 
> I believe the router should not only report the MTU of the outgoing interface, it should also report MTU and MRU of the incoming interface (whatever is smallest, or both).
> 
> I have seen misconfigurations where each side of a link has different MTU/MRU, resulting in PMTUD blackhole with silently dropped packets. If we're serious about this option, we should report whatever is lowest of all MTU/MRU values of incoming and/or outgoing interfaces this packet touched. That would potentially involve including all interfaces this packet could have ECMP:ed egress interface.
> 
> It would also be interesting to have a mechanism along the lines of https://tools.ietf.org/html/draft-van-beijnum-multi-mtu-05 to actually have the routers probe the working MTU between each other, and report that. Whatever option you propose should take this kind of mechanism into account (and use the probed value if that's lower than the interface setting).
> 
> Also, what value should be reported in case of MPLS and varying other encapsulations. I guess the value of the IPv4/IPv6 packet that could fit into the egress interface after all necessary labels etc are put on there?
> 
> So if the egress encap path is two labels deep and the egress MTU is 9180, then 9172 should be reported as IPv4/IPv6 egress MTU as returned by the router when processing this proposed option?
> 
> -- 
> Mikael Abrahamsson    email: swmike@swm.pp.se
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------