Re: [RAM] Tunnelling & GigE jumbo frame size

Dino Farinacci <dino@cisco.com> Wed, 12 September 2007 19:48 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 1IVYC3-0008Pc-99; Wed, 12 Sep 2007 15:48:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVYC2-0008PX-1e for ram@iab.org; Wed, 12 Sep 2007 15:48:10 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVYC0-0000KZ-Su for ram@iab.org; Wed, 12 Sep 2007 15:48:10 -0400
X-IronPort-AV: E=Sophos;i="4.20,246,1186372800"; d="scan'208";a="131760558"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 12 Sep 2007 15:48:12 -0400
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8CJm85B007854; Wed, 12 Sep 2007 15:48:08 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8CJlrEG024852; Wed, 12 Sep 2007 19:48:04 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Sep 2007 15:47:56 -0400
Received: from [192.168.0.3] ([10.82.208.19]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Sep 2007 15:47:56 -0400
In-Reply-To: <6EB2B436-9CA9-4636-802D-B2E64E3E1708@muada.com>
References: <896E7873-B5D5-442E-AB33-63910A6E78BE@extremenetworks.com> <B39B869F-1148-4DC6-A308-02A125F40031@muada.com> <1CD6EB92-9167-4EAE-B372-A517572FCA4D@extremenetworks.com> <E4A2C41B-454D-49CD-852C-B95ACA007971@muada.com> <45779BAC-34BD-49ED-A924-05DF4666FCC6@extremenetworks.com> <6EB2B436-9CA9-4636-802D-B2E64E3E1708@muada.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <2CBC95AD-E817-4A9A-ACDA-26597346B3F8@cisco.com>
Content-Transfer-Encoding: 7bit
From: Dino Farinacci <dino@cisco.com>
Subject: Re: [RAM] Tunnelling & GigE jumbo frame size
Date: Wed, 12 Sep 2007 12:47:58 -0700
To: Iljitsch van Beijnum <iljitsch@muada.com>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 12 Sep 2007 19:47:56.0347 (UTC) FILETIME=[D09FF0B0:01C7F575]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=879; t=1189626488; x=1190490488; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20<dino@cisco.com> |Subject:=20Re=3A=20[RAM]=20Tunnelling=20&=20GigE=20jumbo=20frame=20size |Sender:=20 |To:=20Iljitsch=20van=20Beijnum=20<iljitsch@muada.com>; bh=lxkSNAtQ9IM/HLfL1vGtvAdg2Pn8iKUYODqTvI4d1F4=; b=gs3o0Yd1tfIarTtu6aAXK7Qcp5JFVttlbIJulYt7UwfUceUjBM6dfpfBvDEvpb1w1cCJV84h Rp6qea6XUmZnGvctT7A+fxOn8a6NNK4KZ9oqkAOCAIxlyF2pshpxCBMC;
Authentication-Results: rtp-dkim-2; header.From=dino@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: RJ Atkinson <rja@extremenetworks.com>, 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

> I guess I should read the latest LISP draft as apparently there  
> specific a jumboframe size is mentioned, and I have no idea for  
> what purpose.

To summarize the issue we are trying to put to rest:

o All router-to-router links on the downstream side of an ITR use  
either 4470 or
   9180 byte MTUs.
o We don't care about the links inside a site because a packet is not  
LISP
   encapsulated there (in the typical case of a CE deployment of LISP).
o Hosts can originate 1500 byte sized packets.
o ITRs and TE-ITRs can prepend IPv4 and/or IPv6 headers without  
worrying about
   doing PMTU discovery or fragmentation.

So even when ~80 bytes of IPv6 is used for encapsulation, we have  
enough breathing room to avoid fragmentation (in the event we have 2  
headers, one for purposes of Loc/ID separation and the other for ISP- 
based TE).

Dino

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