Re: [RRG] Re: [RAM] Tunneling overheads and fragmentation

Pekka Savola <pekkas@netcore.fi> Wed, 12 September 2007 06:59 UTC

Return-path: <ram-bounces@iab.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVMCN-00012B-Uz; Wed, 12 Sep 2007 02:59:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVMCM-0000qp-Gp for ram@iab.org; Wed, 12 Sep 2007 02:59:42 -0400
Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVMCL-0007uh-SG for ram@iab.org; Wed, 12 Sep 2007 02:59:42 -0400
Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l8C6xNDG004069; Wed, 12 Sep 2007 09:59:23 +0300
Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l8C6xGX7004066; Wed, 12 Sep 2007 09:59:16 +0300
Date: Wed, 12 Sep 2007 09:59:16 +0300
From: Pekka Savola <pekkas@netcore.fi>
To: Dino Farinacci <dino@cisco.com>
Subject: Re: [RRG] Re: [RAM] Tunneling overheads and fragmentation
In-Reply-To: <78BE8AF3-82FC-4B47-A89A-F67704D89377@cisco.com>
Message-ID: <Pine.LNX.4.64.0709120952580.3261@netcore.fi>
References: <469F7673.6070702@firstpr.com.au> <20070720140433.GA69215@Space.Net> <46A21AD6.2060501@firstpr.com.au> <0857530C-5C9D-4D29-ACAB-16A99CBFD929@muada.com> <46E6992D.2090501@firstpr.com.au> <46E6F514.1030206@gmail.com> <DCE587FE-A4E1-48AB-B378-44A163E2C227@muada.com> <186FA279-5A25-4F50-8CBA-57CD9FDAA925@cisco.com> <A1E7B28B-17AD-42EB-8CBB-743B9558A359@muada.com> <78BE8AF3-82FC-4B47-A89A-F67704D89377@cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Virus-Scanned: ClamAV 0.91.2/4250/Wed Sep 12 03:46:11 2007 on otso.netcore.fi
X-Virus-Status: Clean
X-Spam-Status: No, score=-3.5 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.2.3
X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on otso.netcore.fi
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: Robin Whittle <rw@firstpr.com.au>, RAM Mailing List <ram@iab.org>
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Errors-To: ram-bounces@iab.org

On Tue, 11 Sep 2007, Dino Farinacci wrote:
>> But what about inter-ISP links? I'm assuming this isn't a big issue for 
>> high capacity private peering, but here in Europe a lot of peering happens 
>> over exchanges, which obviously use equipment that can easily handle larger 
>> packets, but so many people are on a big fat shared subnet that it's a 
>> given at someone will bring down the lowest common denominator to 1500.
>
> All GigE and higher. We are okay.

While it may be technically OK, it's nowhere near operationally 
simple, whether or not you count that as "OK".

Many/most inter-ISP links are through GE-based IXes.  I believe most 
of those use a common VLAN for all the peers.  So in order to upgrade 
from MTU 1500, all the ISPs connecting to the VLAN need to update 
basically at once to MTU 9000 or big packets get blackholed to 
non-updated peers.  Another alternative is having a separate "big-MTU 
VLAN", but moving operators from one VLAN to another introduces IP 
address changes, resulting in BGP flaps and rather big operational 
cost.  I believe these big-MTU VLANs haven't been very popular to date 
due to lack of demand (= you'll need to connect to both VLANs in any 
case, and there's rather little benefit _to date_ of supporting 1500+ 
inter-ISP MTUs).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram