Re: [netext] draft-ietf-netext-logical-interface-support -- multiple incompatible MTU advertisements?

Sri Gundavelli <sgundave@cisco.com> Thu, 17 November 2011 03:39 UTC

Return-Path: <sgundave@cisco.com>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA5E1F0CAC for <netext@ietfa.amsl.com>; Wed, 16 Nov 2011 19:39:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcrhnTRMqEZ2 for <netext@ietfa.amsl.com>; Wed, 16 Nov 2011 19:39:53 -0800 (PST)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id D1E551F0C98 for <netext@ietf.org>; Wed, 16 Nov 2011 19:39:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=3100; q=dns/txt; s=iport; t=1321501193; x=1322710793; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=0nvaR9h9Cmf8SKd9epeRiI+sBLwQFOX8glGrRNh0Qes=; b=LoloBj9hUzdDf0Qw7jiTkCDu8o8Z+q1UjBiCqkn6jGbndecLJBS6Z8Vx Dno12UaOg0KSIsvsD0Jvvep8jxEIDIiuMP9ttjr8hBIUNIlG/xiirQx+Z ffpROLDw+Km7pYbc/7J9FCE+logoyv2I/hxOlklHQNbrsH0LGrQI5k1AE E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAB9yxE6rRDoG/2dsb2JhbABCqgaBBYFyAQEBAwEBAQEPAScCATELEgEIGCMyMAIEAQ0FIodgCJR7AZ5gBIoXBIgUjCCFRIxZ
X-IronPort-AV: E=Sophos;i="4.69,524,1315180800"; d="scan'208";a="14680502"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 17 Nov 2011 02:36:50 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAH2ao0X000405; Thu, 17 Nov 2011 02:36:50 GMT
Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Nov 2011 18:36:50 -0800
Received: from 10.21.88.139 ([10.21.88.139]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Thu, 17 Nov 2011 02:36:49 +0000
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 16 Nov 2011 18:36:48 -0800
From: Sri Gundavelli <sgundave@cisco.com>
To: <Basavaraj.Patil@nokia.com>, <charliep@computer.org>
Message-ID: <CAE9B340.30D30%sgundave@cisco.com>
Thread-Topic: [netext] draft-ietf-netext-logical-interface-support -- multiple incompatible MTU advertisements?
Thread-Index: AQHMpAbNXcKzKnB2d0K7cZZ3yVH6bZWu6f6AgAFxdo8=
In-Reply-To: <3987B607-580F-470E-B2C3-9C880356489F@nokia.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 17 Nov 2011 02:36:50.0012 (UTC) FILETIME=[C232A1C0:01CCA4D1]
Cc: netext@ietf.org
Subject: Re: [netext] draft-ietf-netext-logical-interface-support -- multiple incompatible MTU advertisements?
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Nov 2011 03:39:54 -0000

Hi Charlie/Raj:

Agree. This is what we have for the MTU considerations.


5.2.  MTU considerations

   The link MTU (maximum transmission unit) value configured on a
   logical interface should be the lowest of the MTU values supported
   across any of the physical interfaces that are part of that logical
   interface construct.  The MTU value should be configured as part of
   the logical interface creation on the host.

   Furthermore, this value must be updated any time there is a change to
   the logical interface construct, such as when interfaces are added or
   deleted from the logical interface setup.  Any time there is an
   inter-technology handover between two access technologies, the
   applications on the host bound to the IP address configuration on the
   logical interface will not detect the change and will continue to use
   the MTU value of the logical interface for the outbound packets,
   which is never greater than the MTU value on that supported access
   network.  However, the access network may continue to deliver the
   packets conforming to the MTU value supported on that access
   technology and the logical interface should be able to receive those
   packets from the physical interface attached to that network.  This
   approach of MTU configuration will ensure there is no IP packet
   fragmentation after inter-technology handovers.


On 11/15/11 9:34 PM, "Basavaraj.Patil@nokia.com" <Basavaraj.Patil@nokia.com>
wrote:

> 
> Hi Charlie,
> 
> Using the minimum MTU as the value for the logical IF is probably the right
> thing to do.
> However you can also consider this as a sort of a DoS attack in the sense that
> you are forcing the MN to use an MTU to a smaller value thereby causing less
> efficient use of an air IF.
> As an example a wifi network may advertise an MTU of 1280 and if the MN uses
> this as the default even on the cellular IF, the cellular IF is being used sub
> optimally.
> 
> -Basavaraj
> 
> On Nov 16, 2011, at 10:23 AM, ext Charles E. Perkins wrote:
> 
>> 
>> Hello folks,
>> 
>> At the meeting this morning, a question was raised
>> about the proper behavior on a logical interface if
>> more than one value of MTU were advertised on any of
>> the links of the interface.  This was discussed in
>> the IPv6 working group.  IIRC, the sense of the
>> discussion was that this was simply an error.
>> See section 6.2.7 of RFC 4861.
>> 
>> In the case for logical interfaces, it seems to
>> me that (a) a device can pick the MTU for whatever
>> router advertisement it is using and (b) for the
>> purposes of multicast across all links the source
>> should pick the minimum of all advertised values.
>> 
>> Regards,
>> Charlie P.
>> 
>> 
>> Regards,
>> Charlie P.
>> _______________________________________________
>> netext mailing list
>> netext@ietf.org
>> https://www.ietf.org/mailman/listinfo/netext
> 
> _______________________________________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext