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
- RE: [RAM] Tunneling overheads and fragmentation Templin, Fred L
- [RAM] Tunneling overheads and fragmentation Robin Whittle
- [RAM] Re: Tunneling overheads and fragmentation Stephane Bortzmeyer
- Re: [RAM] Re: Tunneling overheads and fragmentati… Iljitsch van Beijnum
- Re: [RAM] Re: Tunneling overheads and fragmentati… David Meyer
- Re: [RAM] Tunneling overheads and fragmentation Wassim Haddad
- Re: [RAM] Tunneling overheads and fragmentation Robin Whittle
- Re: [RAM] Tunneling overheads and fragmentation Gert Doering
- Re: [RAM] Tunneling overheads and fragmentation Robin Whittle
- Re: [RAM] Tunneling overheads and fragmentation Marshall Eubanks
- Re: [RAM] Tunneling overheads and fragmentation Robin Whittle
- Re: [RAM] Tunneling overheads and fragmentation Iljitsch van Beijnum
- Re: [RRG] Re: [RAM] Tunneling overheads and fragm… Iljitsch van Beijnum
- Re: [RRG] Re: [RAM] Tunneling overheads and fragm… Dino Farinacci
- Re: [RRG] Re: [RAM] Tunneling overheads and fragm… Iljitsch van Beijnum
- Re: [RRG] Re: [RAM] Tunneling overheads and fragm… Dino Farinacci
- Re: [RRG] Re: [RAM] Tunneling overheads and fragm… Dino Farinacci
- Re: [RRG] Re: [RAM] Tunneling overheads and fragm… Pekka Savola
- Re: [RRG] Re: [RAM] Tunneling overheads and fragm… Gert Doering
- Re: [RRG] Re: [RAM] Tunneling overheads and fragm… Gert Doering
- Re: [RRG] Re: [RAM] Tunneling overheads and fragm… Dino Farinacci