From ram-bounces@iab.org Thu Sep 06 12:48:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITKWj-0000cd-6O; Thu, 06 Sep 2007 12:48:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITKWi-0000YJ-6H for ram@iab.org; Thu, 06 Sep 2007 12:48:20 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITKWg-0004eM-Mq for ram@iab.org; Thu, 06 Sep 2007 12:48:20 -0400 Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l86GiEmW007474 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Sep 2007 18:44:18 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <468EEF75.3000308@firstpr.com.au> References: <465BA0DB.3070000@firstpr.com.au> <468EEF75.3000308@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5A3C657F-EB84-4229-922F-812356E0C8C5@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] Number of DFZ routers - radical improvement of BGP unlikely Date: Thu, 6 Sep 2007 18:46:36 +0200 To: Robin Whittle X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org [Sorry to again reply many weeks later] On 7-jul-2007, at 3:42, Robin Whittle wrote: > I can't imagine any > backwards-compatible upgrade or incrementally deployable > replacement for BGP could achieve the radical improvements I was > hoping for. > Maybe someone else will have some great ideas for dramatically > souping up BGP. BGP solves some very difficult problems. I can't > think of any drastic improvements. That's an interesting challenge. As the saying goes: given enough thrust, pigs fly just fine. The question is whether it would be easier to replace it. So far, I can't think of anyone else other than myself speaking out in favor of that, or even entertaining the question seriously. :-) Obviously a new protocol would have to be able to interact with BGP and be not much worse at talking BGP than a native speaker. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Sep 06 21:47:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITSwk-0004CG-JQ; Thu, 06 Sep 2007 21:47:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITSwk-0004CB-2c for ram@iab.org; Thu, 06 Sep 2007 21:47:46 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITSwi-0002ld-Tp for ram@iab.org; Thu, 06 Sep 2007 21:47:46 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 773DF872F3; Thu, 6 Sep 2007 21:47:44 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] Number of DFZ routers - radical improvement of BGP unlikely Message-Id: <20070907014744.773DF872F3@mercury.lcs.mit.edu> Date: Thu, 6 Sep 2007 21:47:44 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > From: Iljitsch van Beijnum > The question is whether it would be easier to replace it. So far, I > can't think of anyone else other than myself speaking out in favor of > that, or even entertaining the question seriously. :-) Really? :-) > Obviously a new protocol would have to be able to interact with BGP and > be not much worse at talking BGP than a native speaker. Well, "interact with BGP" and "talk BGP" sound like two very different things to me - unless by "talk BGP" you mean "emulate a BGP speaker". The thing is that if you have a system with a fundamentally different model of the world (e.g. map-based, instead of route-table based), the interface between it and BGP is necessarily going to be something of a kludge, and any emulation is perforce going to be be something less than stellar. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Sep 07 07:27:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITbz9-00017G-4p; Fri, 07 Sep 2007 07:26:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITbz7-00017A-Vn for ram@iab.org; Fri, 07 Sep 2007 07:26:49 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITbz6-0005uW-GE for ram@iab.org; Fri, 07 Sep 2007 07:26:49 -0400 Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l87BMqFh023789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Sep 2007 13:22:57 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <20070907014744.773DF872F3@mercury.lcs.mit.edu> References: <20070907014744.773DF872F3@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] Number of DFZ routers - radical improvement of BGP unlikely Date: Fri, 7 Sep 2007 13:25:15 +0200 To: Noel Chiappa X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.3 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 7-sep-2007, at 3:47, Noel Chiappa wrote: >> From: Iljitsch van Beijnum > >> The question is whether it would be easier to replace it. So far, I >> can't think of anyone else other than myself speaking out in favor of >> that, or even entertaining the question seriously. :-) > Really? :-) Dangers of caching: information from long ago may disappear unless it's refreshed periodically. (-: >> Obviously a new protocol would have to be able to interact with >> BGP and >> be not much worse at talking BGP than a native speaker. > Well, "interact with BGP" and "talk BGP" sound like two very > different things > to me - unless by "talk BGP" you mean "emulate a BGP speaker". Yes, they are different things: there is the protocol, which would be more or less independent from BGP, and the implementation, which would almost certainly need to be able to talk both the new protocol and talk to BGP speakers. Whether this counts as emulating... don't know. > The thing is that if you have a system with a fundamentally > different model > of the world (e.g. map-based, instead of route-table based), the > interface > between it and BGP is necessarily going to be something of a > kludge, and any > emulation is perforce going to be be something less than stellar. At the very least a new protocol would have to support the situation where the new protocol is spoken in the middle and BGP both on the left and on the right. Obviously the BGP speakers may at that point also interact through regular BGP, e.g.: BGP A -- New -- BGP B \ / BGP C (Where "new" may be one or more ASes running the new protocol.) So the new protocol must be able to emulate BGP processing so well that it allows A and B to make (almost) identical decisions as in the case where there was no new protocol. For instance, AS paths must be at least retained and probably be added to as information travels through the new protocol. It gets even more interesting when two clouds speaking the new protocol are separated by a BGP cloud. I don't think an internet-wide map based protocol is feasible, unless aggregation is so draconian that the protocol itself becomes largely irrelevant and operators will mostly be dealing with traffic engineering exceptions rather than the protocol itself. A system where there is a map of the "center" of the network (as seen from a given vantage point) where mapping to/from prefix tables happens at the edges of the map would be very interesting. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Sep 07 09:07:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdY5-000174-I4; Fri, 07 Sep 2007 09:07:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdY5-00016j-6I for ram@iab.org; Fri, 07 Sep 2007 09:07:01 -0400 Received: from imo-m22.mx.aol.com ([64.12.137.3] helo=imo-m22.mail.aol.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITdY3-00006L-Uo for ram@iab.org; Fri, 07 Sep 2007 09:07:01 -0400 Received: from HeinerHummel@aol.com by imo-m22.mx.aol.com (mail_out_v38_r9.2.) id z.c96.1874f3a2 (65100); Fri, 7 Sep 2007 09:06:45 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Fri, 7 Sep 2007 09:06:44 EDT Subject: Re: [RAM] Number of DFZ routers - radical improvement of BGP unlikely To: iljitsch@muada.com, jnc@mercury.lcs.mit.edu MIME-Version: 1.0 X-Mailer: AOL 9.0 VR sub 27 X-Spam-Flag: NO X-Spam-Score: 2.1 (++) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1003761416==" Errors-To: ram-bounces@iab.org --===============1003761416== Content-Type: multipart/alternative; boundary="-----------------------------1189170404" -------------------------------1189170404 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 I am pretty in line with Iljitsch. I also think that it is =20 feasonable/reasonable to have the new design in the middle. At least for an=20= introduction=20 period. When I would talk about 1-2 K FIB entries, I mean of course 1-2 K =20 links,mainly loose links, the more remote, the looser, however precisest in= length. I=20 would also call the database "map-based". But because this is also a routin= g=20 table, the alternative should rather be called "prefix-based". =20 Same remarks about the current stage. We have had a very long discussion about the dual nature id/loc. We never=20 had a discussion about strict/loose links. I mean algorithmically determin= ed=20 loose links. We have adopted the term "stretch" but none of the current models =20 (LISP,lvip,..) has anything to do with it. It takes map-based models, as t= o rate them=20 by stretch values, doesn't it ? (I would claim stretch=3D1 for my map-based= =20 concept of course :-) =20 Another fundamental point of discussion is:=20 Shall a) the IP-header serve the model or b) shall the model serve the=20 IP-header ? We have seen that a) is possible (TOS converted to DSCP). Why not again her= e=20 !?=20 =20 In summary, it is too early to start with the finish. =20 Heiner =20 =20 In einer eMail vom 07.09.2007 13:27:10 Westeurop=E4ische Normalzeit schreibt= =20 iljitsch@muada.com: On 7-sep-2007, at 3:47, Noel Chiappa wrote: >> From: Iljitsch van Beijnum > >> The question is whether it would be easier to replace it. So far, I >> can't think of anyone else other than myself speaking out in favor of >> that, or even entertaining the question seriously. :-) > Really? :-) Dangers of caching: information from long ago may disappear unless =20 it's refreshed periodically. (-: >> Obviously a new protocol would have to be able to interact with =20 >> BGP and >> be not much worse at talking BGP than a native speaker. > Well, "interact with BGP" and "talk BGP" sound like two very =20 > different things > to me - unless by "talk BGP" you mean "emulate a BGP speaker". Yes, they are different things: there is the protocol, which would be =20 more or less independent from BGP, and the implementation, which =20 would almost certainly need to be able to talk both the new protocol =20 and talk to BGP speakers. Whether this counts as emulating... don't =20 know. > The thing is that if you have a system with a fundamentally =20 > different model > of the world (e.g. map-based, instead of route-table based), the =20 > interface > between it and BGP is necessarily going to be something of a =20 > kludge, and any > emulation is perforce going to be be something less than stellar. At the very least a new protocol would have to support the situation =20 where the new protocol is spoken in the middle and BGP both on the =20 left and on the right. Obviously the BGP speakers may at that point =20 also interact through regular BGP, e.g.: BGP A -- New -- BGP B \ / BGP C (Where "new" may be one or more ASes running the new protocol.) So =20 the new protocol must be able to emulate BGP processing so well that =20 it allows A and B to make (almost) identical decisions as in the case =20 where there was no new protocol. For instance, AS paths must be at =20 least retained and probably be added to as information travels =20 through the new protocol. It gets even more interesting when two =20 clouds speaking the new protocol are separated by a BGP cloud. I don't think an internet-wide map based protocol is feasible, unless =20 aggregation is so draconian that the protocol itself becomes largely =20 irrelevant and operators will mostly be dealing with traffic =20 engineering exceptions rather than the protocol itself. A system =20 where there is a map of the "center" of the network (as seen from a =20 given vantage point) where mapping to/from prefix tables happens at =20 the edges of the map would be very interesting. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram =20 -------------------------------1189170404 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
I am pretty in line  with Iljitsch. I also think that it= is=20 feasonable/reasonable to have the new design in the middle. At least for an=20 introduction period.
When I would talk about 1-2 K FIB entries, I mean of course 1-2 K=20 links,mainly loose links, the more remote, the looser,=20 however precisest in length. I would also call the=20 database "map-based". But because this is also a routing table, the=20 alternative should rather be called "prefix-based".
 
Same remarks about the current stage.
We have had a very long discussion about the dual nature id/l= oc.=20 We never had a discussion about strict/loose links. I mean  algorithmic= ally=20 determined loose links.
We have adopted the term "stretch" but none of the current models=20 (LISP,lvip,..) has anything to do with it. It takes  map-based models,=20= as=20 to rate them by stretch values, doesn't it ? (I would claim stretch=3D1 for=20= my=20 map-based concept of course :-)
 
Another fundamental point of discussion is:
Shall a) the IP-header  serve the model or b) shall the model serv= e=20 the IP-header ?
We have seen that a) is possible (TOS converted to DSCP). Why not again= =20 here !?
 
In summary, it is too early to start with the finish.
 
Heiner 
 
In einer eMail vom 07.09.2007 13:27:10 Westeurop=E4ische Normalzeit sch= reibt=20 iljitsch@muada.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>On=20 7-sep-2007, at 3:47, Noel Chiappa wrote:

>> From: Iljitsch va= n=20 Beijnum <iljitsch@muada.com>
>
>> The question is whe= ther=20 it would be easier to replace it. So far, I
>> can't think of any= one=20 else other than myself speaking out in favor of
>> that, or even=20 entertaining the question seriously. :-)

> Really?=20 :-)

Dangers of caching: information from long ago may disappear=20 unless 
it's refreshed periodically.  (-:

>>=20 Obviously a new protocol would have to be able to interact with =20
>> BGP and
>> be not much worse at talking BGP than a=20 native speaker.

> Well, "interact with BGP" and "talk BGP" sound= =20 like two very 
> different things
> to me - unless by "t= alk=20 BGP" you mean "emulate a BGP speaker".

Yes, they are different thin= gs:=20 there is the protocol, which would be 
more or less independent f= rom=20 BGP, and the implementation, which 
would almost certainly need t= o be=20 able to talk both the new protocol 
and talk to BGP speakers. Whe= ther=20 this counts as emulating... don't 
know.

> The thing is= =20 that if you have a system with a fundamentally 
> different=20 model
> of the world (e.g. map-based, instead of route-table based),= =20 the 
> interface
> between it and BGP is necessarily goi= ng=20 to be something of a 
> kludge, and any
> emulation is=20 perforce going to be be something less than stellar.

At the very le= ast=20 a new protocol would have to support the situation 
where the new= =20 protocol is spoken in the middle and BGP both on the 
left and on= the=20 right. Obviously the BGP speakers may at that point 
also interac= t=20 through regular BGP, e.g.:

BGP A -- New -- BGP B
   =20    \       /
     =20    BGP C

(Where "new" may be one or more ASes running the= new=20 protocol.) So 
the new protocol must be able to emulate BGP=20 processing so well that 
it allows A and B to make (almost) ident= ical=20 decisions as in the case 
where there was no new protocol. For=20 instance, AS paths must be at 
least retained and probably be add= ed=20 to as information travels 
through the new protocol. It gets even= =20 more interesting when two 
clouds speaking the new protocol are=20 separated by a BGP cloud.

I don't think an internet-wide map based=20 protocol is feasible, unless 
aggregation is so draconian that th= e=20 protocol itself becomes largely 
irrelevant and operators will mo= stly=20 be dealing with traffic 
engineering exceptions rather than the=20 protocol itself. A system 
where there is a map of the "center" o= f=20 the network (as seen from a 
given vantage point) where mapping=20 to/from prefix tables happens at 
the edges of the map would be v= ery=20 interesting.

_______________________________________________
RAM= =20 mailing=20 list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram
 
 -------------------------------1189170404-- --===============1003761416== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1003761416==-- From ram-bounces@iab.org Fri Sep 07 09:12:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITddI-00048F-Vl; Fri, 07 Sep 2007 09:12:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITddH-00046Z-QW for ram@iab.org; Fri, 07 Sep 2007 09:12:23 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITddG-0000Cq-FN for ram@iab.org; Fri, 07 Sep 2007 09:12:23 -0400 Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l87D8a8Y025658 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Sep 2007 15:08:37 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <380DB505-2581-4E48-B413-37BB6AB6272F@virtualized.org> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.nt dev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.nt dev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <4641750A.9010906@cisco.com> <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> <4641F33B.4070103@cisco.com> <2CB91D98-4CA3-4F4E-A2F6-CFEF5E04C0DB@virtualized.org> <380DB505-2581-4E48-B413-37BB6AB6272F@virtualized.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <990A1601-377B-4F54-82D7-CDAA0757E269@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Fri, 7 Sep 2007 15:10:59 +0200 To: David Conrad X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org [sorry, replying to an even older message... but I think this is important] On 9-mei-2007, at 20:07, David Conrad wrote: > If an application works today, I'm having trouble understanding how > the introduction of additional O(10-100ms) latencies in the event > of a cache miss (which will likely only occur at the first packet > in a packet train) is going to have significant impact. In those > odd cases that there is an impact, how much work would it be to > modify the application operation to be more tolerant of network > delays? I'm assuming an encapsulation device close to the source host that serves more than a single host, and maybe even a great number of hosts. If nothing much is happening and caches are empty, and a host then starts a session towards some remote destination, in a pull model, the encapsulating device must first look up a mapping so it can perform the required encapsulation. So the first packet must be dropped. At the start of a session, that would be the first TCP SYN (or equivalent packet for other transport protocols). At this point, it doesn't matter all that much how fast the mapping information becomes available, because the application has to wait for a retransmission of the first packet. Obviously it doesn't help if the mapping system is so slow that the second packet is also dropped. But I think 10 - 100 ms is extremely optimistic, DNS is about an order of magnitude slower than that in practice and it takes ~ 350 ms round trip across the world. So the difference here is that unlike with the DNS, where you can proceed as soon as there is an answer, you have to time out here, and both doing that too fast and too slow increases latency. But that's only when the sky is blue and the sun is shining. When an encapsulation device suddenly gets a lot of traffic that has been going for a while, so it's happening at high speeds, but it somehow doesn't have any mapping state (mapping state timed out, rerouting between encapsulation devices, maybe even a reboot), very many packets will be lost while a mapping lookup is done. Also, if a large number of flows require mapping requests, it's entirely possible that these must be rate limited, increasing delays even further. I guess it would be possible for the encapsulation device to send a message back to the source host that indicates that the packet was dropped so it should be retransmitted. I'm guessing TCP will do that for ICMP "packet too big" messages today. However, I would prefer "initial non-optimizedness" over "initial loss". If there is some place packets for destinations that aren't mapped yet can be sent to so they arrive anyway, even if this path is slower, this takes a lot of pressure off of the encapsulation devices, making the downsides of pull and caching less problematic: mapping requests can be done at the rate that best suit the encapsulation device rather than as fast as possible to avoid application impact. I suppose there are some applications that will try to judge network characteristics based on the first few packets, and in such a situation, they would come to unnecessarily conservative conclusions. However, this could be addressed by changing these applications rather than restricting the internet architecture. The issue of determining rendezvous locations that Marshall brought up is simple enough: have each rendezvous point handle a very long prefix, such as 96.0.0.0/6. This of course sucks if you have 97.0.0.1 and you're in South Africa while the relevant rendezvous point for 96.0.0.0/6 is in Japan, but since the detour only happens for the first few packets this shouldn't be a huge issue. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Sep 09 22:17:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUYp6-0001n9-GT; Sun, 09 Sep 2007 22:16:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUYp5-0001n4-JG for ram@iab.org; Sun, 09 Sep 2007 22:16:23 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUYp4-0005Xb-E6 for ram@iab.org; Sun, 09 Sep 2007 22:16:23 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id E482D87322; Sun, 9 Sep 2007 22:16:21 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] The mapping problem: rendezvous points? Message-Id: <20070910021621.E482D87322@mercury.lcs.mit.edu> Date: Sun, 9 Sep 2007 22:16:21 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: jnc@mercury.lcs.mit.edu X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > From: Iljitsch van Beijnum > If nothing much is happening and caches are empty, and a host then > starts a session towards some remote destination, in a pull model, the > encapsulating device must first look up a mapping so it can perform the > required encapsulation. So the first packet must be dropped. Well, is that latter really necessary? I know it's more complex to hold onto the packet until the mapping comes back, but if dropping that first packet causes problems, we could write that code without changing anything else in the system; i.e. it's an optimization we can add later, invisibly to the rest of the system, if it turns out we need it. > If there is some place packets for destinations that aren't mapped yet > can be sent to so they arrive anyway, even if this path is slower, this > takes a lot of pressure off of the encapsulation devices, Interesting idea. Let me ponder that... > The issue of determining rendezvous locations .. is simple enough: have > each rendezvous point handle a very long prefix, such as 96/6. How about piggybacking the user's data packet on the request for the EID->RLOC binding? When the request gets to whereever that binding is available, it's sent on to the ETR, while the mapping is sent back to the requestor? That avoids all the extra mechanism/configuration of rendezvous points. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Sep 09 22:26:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUYxv-0003fr-2Q; Sun, 09 Sep 2007 22:25:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUYxt-0003ff-Gd for ram@iab.org; Sun, 09 Sep 2007 22:25:29 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUYxs-0005io-Ct for ram@iab.org; Sun, 09 Sep 2007 22:25:29 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 2DF6A87322; Sun, 9 Sep 2007 22:25:28 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] Number of DFZ routers - radical improvement of BGP unlikely Message-Id: <20070910022528.2DF6A87322@mercury.lcs.mit.edu> Date: Sun, 9 Sep 2007 22:25:28 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.3 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > From: Iljitsch van Beijnum > At the very least a new protocol would have to support the situation > where the new protocol is spoken in the middle and BGP both on the left > and on the right. Right, and if the fundamental concepts of the new design are very different from those of BGP (e.g. it exchages maps, rather than routing table entries), that translation, forwards and backwards, could be rather tricky. > It gets even more interesting when two clouds speaking the new protocol > are separated by a BGP cloud. Now you're either i) limiting the new system to having the capabilities of BGP (in which case, you lose a lot of the point of doing something new), or ii) you have to accept that two such discontiguous regions of New Stuff simply don't get all the benefits of New Stuff until they somehow manage to connect directly. > I don't think an internet-wide map based protocol is feasible We will have to agree to differ... :-) > A system where there is a map of the "center" of the network (as seen > from a given vantage point) where mapping to/from prefix tables > happens at the edges of the map would be very interesting. It happens that map-based system are ideally suited to building systems where eveyone has a different view of the network... Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Sep 10 03:44:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUdwJ-0003ms-QD; Mon, 10 Sep 2007 03:44:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUdwH-0003aD-WC for ram@iab.org; Mon, 10 Sep 2007 03:44:10 -0400 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUdwG-0004CJ-IF for ram@iab.org; Mon, 10 Sep 2007 03:44:09 -0400 Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 08:44:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] The mapping problem: rendezvous points? Date: Mon, 10 Sep 2007 08:44:17 +0100 Message-ID: In-Reply-To: <20070910021621.E482D87322@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] The mapping problem: rendezvous points? Thread-Index: AcfzVOsbD1ps74OuRi6fMQDJkwV9aQAKTgQg From: To: , X-OriginalArrivalTime: 10 Sep 2007 07:44:07.0161 (UTC) FILETIME=[5DFC8E90:01C7F37E] X-Spam-Score: -1.0 (-) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org =20 -----Original Message----- From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 Sent: 10 September 2007 03:16 To: ram@iab.org Cc: jnc@mercury.lcs.mit.edu Subject: Re: [RAM] The mapping problem: rendezvous points? > From: Iljitsch van Beijnum > If nothing much is happening and caches are empty, and a host then > starts a session towards some remote destination, in a pull model, the > encapsulating device must first look up a mapping so it can perform the > required encapsulation. So the first packet must be dropped. Well, is that latter really necessary? I know it's more complex to hold onto the packet until the mapping comes back, but if dropping that first packet causes problems, we could write that code without changing anything else in the system; i.e. it's an optimization we can add later, invisibly to the rest of the system, if it turns out we need it. [alb] If the pull takes a while, someone could send lots of packets to dud destinations, and if you hold all those packets waiting to find the mapping you have DoS potential? _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Sep 10 05:00:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUf8O-0008LY-AW; Mon, 10 Sep 2007 05:00:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUf8O-0008LR-0Y for ram@iab.org; Mon, 10 Sep 2007 05:00:44 -0400 Received: from imo-d23.mx.aol.com ([205.188.139.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUf8M-0006Ei-IU for ram@iab.org; Mon, 10 Sep 2007 05:00:43 -0400 Received: from HeinerHummel@aol.com by imo-d23.mx.aol.com (mail_out_v38_r9.2.) id 9.c76.1b00643f (42807); Mon, 10 Sep 2007 05:00:36 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Mon, 10 Sep 2007 05:00:36 EDT Subject: Re: [RAM] Number of DFZ routers - radical improvement of BGP unlikely To: jnc@mercury.lcs.mit.edu, ram@iab.org MIME-Version: 1.0 X-Mailer: AOL 9.0 VR sub 27 X-Spam-Flag: NO X-Spam-Score: 2.1 (++) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2041291568==" Errors-To: ram-bounces@iab.org --===============2041291568== Content-Type: multipart/alternative; boundary="-----------------------------1189414836" -------------------------------1189414836 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 In einer eMail vom 10.09.2007 04:26:40 Westeurop=E4ische Normalzeit schreibt= =20 jnc@mercury.lcs.mit.edu: > It gets even more interesting when two clouds speaking the new protocol > are separated by a BGP cloud. that would be l'art pour l'art, but makes no sense - IMHO =20 Heiner =20 -------------------------------1189414836 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 10.09.2007 04:26:40 Westeurop=E4ische Normalzeit sch= reibt=20 jnc@mercury.lcs.mit.edu:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2> =20   > It gets even more interesting when two clouds speaking the new= =20 protocol
    > are separated by a BGP=20 cloud.

that would be l'art pour l'art, but makes no sense - IMHO
 
Heiner
-------------------------------1189414836-- --===============2041291568== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============2041291568==-- From ram-bounces@iab.org Mon Sep 10 09:05:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUixJ-000469-T3; Mon, 10 Sep 2007 09:05:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUixH-00045z-Rm for ram@iab.org; Mon, 10 Sep 2007 09:05:31 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUixG-0004Sx-7j for ram@iab.org; Mon, 10 Sep 2007 09:05:31 -0400 Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l8AD1Lk8088083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Sep 2007 15:01:26 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <46A21AD6.2060501@firstpr.com.au> References: <469F7673.6070702@firstpr.com.au> <20070720140433.GA69215@Space.Net> <46A21AD6.2060501@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0857530C-5C9D-4D29-ACAB-16A99CBFD929@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] Tunneling overheads and fragmentation Date: Mon, 10 Sep 2007 15:03:50 +0200 To: Robin Whittle X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org [caught up, yay!] On 21-jul-2007, at 16:40, Robin Whittle wrote: > Even then, I fear that in order to preserve both reachability and > efficiency (and any reachability problems which arise from > fragmentation), that hosts in all networks, including non-upgraded > networks, will need to adopt a somewhat lower MTU setting - for > all the packets they send. That would assume that there is something that doesn't support the "regular" MTU (in theory, there is no such thing, in practice: 1500 bytes) between the place the packets are encapsulated and the place the packets are decapsulated. I'm still operating under the assumption that both those places are in ISP networks. Now obviously there are lots of places in ISP networks that only support 1500-byte packets, but what would be a better decision here: push out a reduced packet size EVERYWHERE which we probably won't be able to raise any time soon, or require ISPs to either: 1. Implement path MTU discovery correctly, or: 2. Make sure that all encapsulated packets travel over paths that support at least 1500 byte + encapsulation sized packets > I wonder to what extent every possible application respects the > operating system's MTU. The two are unrelated. Applications talk to transport protocols. The most popular one, TCP, breaks large chunks of data into smaller segments and coalesces multiple small chunks into larger segments. UDP simply adds its header and hands over the packet to the IP layer. The IP layer will fragment packets that are too large to be sent out over the interface of choice and/or the packet's destination. The only time there are problems (except of course from firewalls that don't like fragmentation) is when the transport protocol or application doesn't want fragmentation (DF=1) but the packet is larger than the interface MTU. Not sure what happens then, except that there is no way that a packet larger than the interface MTU is sent in one piece. > I wonder if there are any widely > used applications, such as games, P2P programs etc. which are > hard-coded to assume a certain MTU which is close to, or right at, > the limit of what can safely be sent across most of the Net. Mostly video streaming, although that's all quickly moving to TCP these days. A common packet size here is 1450 bytes but I think that's excluding 28 bytes IPv4 + UDP so the packets are really 1478 bytes. I also remember seeing fragmented TCP traffic coming from DSL users. Obviously some link didn't do 1500 bytes in the middle but rather than use PMTUD the devices involved fragmented. I think DF wasn't set in this case, but it could have been cleared by a router or other box somewhere along the way. (I once implemented that myself when I got dial-up service delivered over a tunnel that only supported a 576- byte MTU.) > Perhaps, in an optimistic scenario, recognising that some packets > are to be encapsulated by ITRs, an ISP network could set up its > DHCP system or whatever it is which gives DSL modems their > parameters, to reduce the MTU and MSS settings sufficiently that > the ITR-applied encapsulation still results in packets which will > not be fragmented in most transit and border routers. There are several MTU-related DHCP options but I'm not sure how widely they are supported. Note by the way that ATM which is used for both ADSL and DOCSIS (cable) supports MTUs much larger than 1500 bytes. By the way, I'm currently working on this: http://www.ietf.org/internet-drafts/draft-van-beijnum-multi-mtu-01.txt It doesn't directly address this issue but it allows for systems with different MTUs to coexist on the same subnet so it becomes a lot easier to deploy jumboframes. > This really needs to be done for all hosts in all networks - not > just hosts in networks which have been upgraded with ITRs and ETRs > etc. Oh joy. Doing path MTU discovery is probably easier, and note that if one host in a TCP session has a reduced MTU, it will let the other know during the three-way handshake so the unencumbered host won't send packets that are too large. > Even if the host had its own ITFH > (Ingress Tunnel Function in Host) function, I don't see how the > operating system could tell application programs that there is one > MTU and MSS setting for packets going to some addresses and > another setting for packets going to other addresses. Not a problem, path MTU discovery already does this today. However, I see issues with hosts doing their own en/decapsulation: that way, the locators are exposed to hosts and they are at risk for becoming just as unrenumberable as IP addresses today. The only way to make sure that you can renumber easily is if there are no firewall rules looking at locators. And the only way that will happen is if the relationship between location and identity is strong enough that spoofing it is not a viable attack vector. Concretely: today the routing system is unspoofable enough that people filter on IP addresses. The routing system is run by service providers who generally aren't in the business of attacking people. But if a locator mapping system is also open to end-users, it may be possible for attacks to use this path and people won't be happy to filter on just identifiers, just like they aren't happy to filter on just DNS names today. So either the ISPs must run it or there must be a heavy layer of magic security dust. > UDP encapsulation, as used by LISP and I think eFIT-APT, involves > 20 bytes for the IP header, 8 bytes for the UDP header and some > number of bytes, such as 4, for extra stuff What exactly was the reason for UDP encapsulation again? I think Dino said something about load balancing and firewalling. I'm not buying that: you can load balance on the destination IP address and anyone running firewalls in the middle of the routing system is best served with a single deny any any rule. > This is where IPv6's long addresses and headers become really > ugly. There would be 40 bytes for IP-in-IP and 52 for basic UDP > encapsulation. We really need bigger packets to offset the ever-increasing overhead. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Sep 10 09:15:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUj74-00028s-4a; Mon, 10 Sep 2007 09:15:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUj73-00025E-0b for ram@iab.org; Mon, 10 Sep 2007 09:15:37 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUj71-0004j4-Mf for ram@iab.org; Mon, 10 Sep 2007 09:15:36 -0400 Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l8ADBiRp088267 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Sep 2007 15:11:44 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <20070910021621.E482D87322@mercury.lcs.mit.edu> References: <20070910021621.E482D87322@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <43931B1D-80A1-45B5-A598-F0446CB536CB@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Mon, 10 Sep 2007 15:14:11 +0200 To: Noel Chiappa X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 10-sep-2007, at 4:16, Noel Chiappa wrote: >> If nothing much is happening and caches are empty, and a host then >> starts a session towards some remote destination, in a pull model, >> the >> encapsulating device must first look up a mapping so it can >> perform the >> required encapsulation. So the first packet must be dropped. > Well, is that latter really necessary? "Routers are not in the storage business." But if they were, there would be a limit to what they can store, and I think it's likely this limit is smaller than the maximum number of packets that the router can receive in the maximum time it can take until the mapping process completes. So I'd say that drops will happen, even if some storage is added as an optimization. >> If there is some place packets for destinations that aren't mapped >> yet >> can be sent to so they arrive anyway, even if this path is slower, >> this >> takes a lot of pressure off of the encapsulation devices, > Interesting idea. Let me ponder that... >> The issue of determining rendezvous locations .. is simple enough: >> have >> each rendezvous point handle a very long prefix, such as 96/6. > How about piggybacking the user's data packet on the request for the > EID->RLOC binding? Wouldn't that be a specific implementation of the general idea of sending packets for which there is no mapping to a location that knows how to deliver them? > When the request gets to whereever that binding is > available, it's sent on to the ETR, while the mapping is sent back > to the > requestor? That avoids all the extra mechanism/configuration of > rendezvous > points. It's a tradeoff between the complexity of having an additional system or the complexity of having multiple functions in one system. I'd say that it would be good to design things such that it's possible to do it in separate rendezvous points and then let the implementers figure out whether they want to do it that way or not. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Sep 10 16:08:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUpYB-0005fV-VS; Mon, 10 Sep 2007 16:08:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUpYA-0005fQ-QP for ram@iab.org; Mon, 10 Sep 2007 16:08:02 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUpY9-0002JH-Kk for ram@iab.org; Mon, 10 Sep 2007 16:08:02 -0400 X-IronPort-AV: E=Sophos;i="4.20,233,1186372800"; d="scan'208";a="70665692" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 10 Sep 2007 16:07:59 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8AK81RA026836; Mon, 10 Sep 2007 16:08:01 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8AK7mC6029540; Mon, 10 Sep 2007 20:07:59 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); Mon, 10 Sep 2007 16:07:52 -0400 Received: from [10.225.24.82] ([10.82.218.139]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 16:07:52 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <415D3A2C-8DBC-4F3B-847D-8032D37B2D1E@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Mon, 10 Sep 2007 13:07:51 -0700 To: "" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 Sep 2007 20:07:52.0521 (UTC) FILETIME=[44C61B90:01C7F3E6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1179; t=1189454881; x=1190318881; 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 |Subject:=20Re=3A=20[RAM]=20The=20mapping=20problem=3A=20rendezvous=20poi nts? |Sender:=20 |To:=20=22=22=20; bh=yMsUupxWEuM6sfa1ITCt/PFdlJ4/LvIRTM7nNQzq8S8=; b=HDS3fJ2TaeyPQKV+YApZMUid+/cppz1lpTkbDLpeSBOIpO+8j3xVZodHeoO9T7ncaynLvW1q Qn0+gfXPZvnuNxRf2AMavMi/2BOHUdsT1sqkWBwxo0zzKzBEtH3KtU4L; 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: ea4ac80f790299f943f0a53be7e1a21a Cc: jnc@mercury.lcs.mit.edu, ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >> From: Iljitsch van Beijnum > >> If nothing much is happening and caches are empty, and a host then >> starts a session towards some remote destination, in a pull model, > the >> encapsulating device must first look up a mapping so it can > perform the >> required encapsulation. So the first packet must be dropped. > > Well, is that latter really necessary? I know it's more complex to > hold > onto the packet until the mapping comes back, but if dropping that > first > packet causes problems, we could write that code without changing > anything else in the system; i.e. it's an optimization we can add > later, > invisibly to the rest of the system, if it turns out we need it. This is the reason why the data-triggered based Map-Reply in LISP takes a packet that does not have a mapping cached and copies the inner destination address to the outer header's destination address field. And hence LISP 1.5 allows no drop of packets if an EID-prefix namespace is routed on another topology where you only route on IDs (where the Internet topology we know of today routes only on locator prefixes). Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Sep 10 19:07:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUsLi-0001sE-0T; Mon, 10 Sep 2007 19:07:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUsLg-0001s2-Cq for ram@iab.org; Mon, 10 Sep 2007 19:07:20 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUsLf-0007lr-7c for ram@iab.org; Mon, 10 Sep 2007 19:07:20 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id DB9E7872FC; Mon, 10 Sep 2007 19:07:18 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] The mapping problem: rendezvous points? Message-Id: <20070910230718.DB9E7872FC@mercury.lcs.mit.edu> Date: Mon, 10 Sep 2007 19:07:18 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: jnc@mercury.lcs.mit.edu X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > From: Dino Farinacci > if an EID-prefix namespace is routed on another topology where you only > route on IDs (where the Internet topology we know of today routes only > on locator prefixes) Err, minor terminological nit: one my definitions of "locator" is 'names used by the path-selection system'. So if you have a system which is doing "rout[ing]" (i.e. doing next-hop selection along the path), then the things it is using as the name of the destination are, *by definition*, locators... even if you call them EIDs! Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Sep 11 10:27:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV6iR-0001cn-DS; Tue, 11 Sep 2007 10:27:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV6iP-0001cV-Vw for ram@iab.org; Tue, 11 Sep 2007 10:27:45 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV6iO-0004Rk-P1 for ram@iab.org; Tue, 11 Sep 2007 10:27:45 -0400 X-IronPort-AV: E=Sophos;i="4.20,238,1186383600"; d="scan'208";a="175413631" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 11 Sep 2007 07:27:44 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8BERiKu012657; Tue, 11 Sep 2007 07:27:44 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8BERgoZ019693; Tue, 11 Sep 2007 14:27:44 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 07:27:40 -0700 Received: from [10.224.130.4] ([10.21.92.242]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 07:27:39 -0700 In-Reply-To: <20070910230718.DB9E7872FC@mercury.lcs.mit.edu> References: <20070910230718.DB9E7872FC@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7118BA24-929B-4AF9-BEB6-3769F6175A65@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Tue, 11 Sep 2007 07:27:39 -0700 To: Noel Chiappa X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 11 Sep 2007 14:27:39.0806 (UTC) FILETIME=[E842BBE0:01C7F47F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1238; t=1189520864; x=1190384864; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20The=20mapping=20problem=3A=20rendezvous=20poi nts? |Sender:=20; bh=nn2vrTadTdN1bX3vXCPDqI5Nn+gcq7alNvIsONeMzik=; b=r1ZEjyOaBlzJDYGqleSRu0/puO6Q1ZDa+9qzxzr92oHsUp+6DMMh63YVh+sJ3HgABowvIrDY amSCijSRi9bT8zYvVNNFbXgknR+haItIh/5tZFOseqOiVL7uAn/jSVGh; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > > From: Dino Farinacci > > > if an EID-prefix namespace is routed on another topology > where you only > > route on IDs (where the Internet topology we know of today > routes only > > on locator prefixes) > > Err, minor terminological nit: one my definitions of "locator" is > 'names used > by the path-selection system'. So if you have a system which is doing > "rout[ing]" (i.e. doing next-hop selection along the path), then > the things > it is using as the name of the destination are, *by definition*, > locators... > even if you call them EIDs! I agree with your definition, but in LISP 1 and 1.5, when you copy the inner DA to the outer DA, we call the inner DA an EID because it is assigned to a host. And we use that EID as a locator in the IGP. When it is copied to the outer DA for map resolution, I guess it is also a locator outside of the site. But the semantic of this outer DA, in lieu of map resolution comes out of the EID-prefix allocation space and not an ISPs space. So I know this can be confusing or controversial, but when I look at an address, I call it from where it was *allocated* from and not how it is used. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Sep 11 15:42:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVBdQ-0000Yj-Ej; Tue, 11 Sep 2007 15:42:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVBdN-0000H8-WA for ram@iab.org; Tue, 11 Sep 2007 15:42:54 -0400 Received: from eastrmmtao107.cox.net ([68.230.240.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVBdM-0005Ay-Gl for ram@iab.org; Tue, 11 Sep 2007 15:42:53 -0400 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao107.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20070911194251.CELO25010.eastrmmtao107.cox.net@eastrmimpo01.cox.net> for ; Tue, 11 Sep 2007 15:42:51 -0400 Received: from [10.30.20.61] ([68.10.115.231]) by eastrmimpo01.cox.net with bizsmtp id n7ir1X00L4zdCG40000000; Tue, 11 Sep 2007 15:42:51 -0400 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: ram@iab.org From: RJ Atkinson Date: Tue, 11 Sep 2007 15:42:50 -0400 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [RAM] Re: The mapping problem: rendezvous points ? X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Originally, Noel said: > Err, minor terminological nit: one my definitions of "locator" is > 'names used by the path-selection system'. So if you have a system > which is doing "rout[ing]" (i.e. doing next-hop selection along the > path), then the things it is using as the name of the destination are, > *by definition*, locators... even if you call them EIDs! Later on, Dino said: % I agree with your definition, but in LISP 1 and 1.5, when you copy the % inner DA to the outer DA, we call the inner DA an EID because it is % assigned to a host. And we use that EID as a locator in the IGP. % When it is copied to the outer DA for map resolution, I guess it % is also a locator outside of the site. The Internet community has a well understood name for objects that are used sometimes as identifiers and sometimes for routing/forwarding. Normally, these objects with mixed semantics are called "addresses", not "EIDs" and not "Locators". I really think that people would have an easier time understanding the various proposals (not just LISP) if we really would move to crisper terminology usage. Cheers, Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Sep 11 17:03:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVCtE-0006r5-NF; Tue, 11 Sep 2007 17:03:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVCtD-0006mc-AQ for ram@iab.org; Tue, 11 Sep 2007 17:03:19 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVCtB-0007G7-QD for ram@iab.org; Tue, 11 Sep 2007 17:03:19 -0400 Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l8BKxIhI018940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Sep 2007 22:59:21 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <46E6F514.1030206@gmail.com> 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> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RRG] Re: [RAM] Tunneling overheads and fragmentation Date: Tue, 11 Sep 2007 23:01:44 +0200 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Robin Whittle , RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org [back on RAM because I believe that's where the LISP folks hang out and this is relevant for them, besides, people may think I'm a researcher...] On 11-sep-2007, at 22:05, Brian E Carpenter wrote: >>> I'm still operating under the assumption that both those places >>> are in >>> ISP networks. Now obviously there are lots of places in ISP networks >>> that only support 1500-byte packets, > Can somebody provide evidence for this statement? Minira#conf t Enter configuration commands, one per line. End with CNTL/Z. Minira(config)#interface fastEthernet 1/0 Minira(config-if)#ip mtu ? <68-1500> MTU (bytes) Granted, this is a fairly old box in a small network, but I don't see anyone seriously claiming that ALL ISP networks support packets larger than 1500 bytes on ALL their internal links (and also on inter- ISP links). That said, it may very well be feasible to engineer a "jack up" solution such that the encapsulated = larger packets only see parts of networks that support more than 1500 bytes with a level of effort that is within reason. (Let me put it this way: what's easier to support: a million prefix in the routing table or a 1600 byte MTU?) >>> but what would be a better decision >>> here: push out a reduced packet size EVERYWHERE which we probably >>> won't >>> be able to raise any time soon, or require ISPs to either: >>> 1. Implement path MTU discovery correctly, or: >>> 2. Make sure that all encapsulated packets travel over paths that >>> support at least 1500 byte + encapsulation sized packets >> All these options look impossible or ugly to me. > The first one has been eluding us for years, but the network > still works. What's the evidence on actual deployment? (Also > see below.) Please note that this is about the network between *TRs, which is a much simpler universe than the host-to-host universe where weird OSes, NAT and firewalls get in the way. (Again, assuming that end- users don't get to run en/decapsulation boxes themselves.) > The second one sounds like something that is in the ISPs' > enlightened self interest, in which case it will happen. Right. However, that would probably still be a deployment problem because we may have to wait for upgrades to happen. Elsewhere, I was more or less dragged into a discussion about tunnel MTU issues. Believe me when I tell you that this is a minefield. However, the good thing with a LISP-like solution is that we get to design everything on all ends (ITR, ETR, mapping) so it's not too hard to implement fragmentation at the encapsulation layer. The issue with IPv4 encapsulation is that the ID space is too small to support decent packet rates. With something like LISP, we can implement an ID field there and severely tighten the reassembly window (maybe even go so far that fragments from one source must arrive in-order) so this works much better. The mapping system could distribute MTU/MRU information if that's helpful. [...] > Hence RFC 4821, which does need to get deployed. RFC 4821 (PMTUD without ICMP) is great for TCP, but it's not reasonably implementable for most UDP-based protocols/applications. It also suffers from the problem that you don't know if your corresponent supports it so it requires a leap of faith that things will work out. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Sep 11 17:41:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVDUZ-0004LT-AV; Tue, 11 Sep 2007 17:41:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVDUY-0004Ki-K7 for ram@iab.org; Tue, 11 Sep 2007 17:41:54 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVDUX-0007yT-EC for ram@iab.org; Tue, 11 Sep 2007 17:41:54 -0400 X-IronPort-AV: E=Sophos;i="4.20,240,1186372800"; d="scan'208";a="131670802" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 11 Sep 2007 17:41:50 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8BLfr8D021260; Tue, 11 Sep 2007 17:41:53 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8BLfcEO019838; Tue, 11 Sep 2007 21:41:43 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 17:41:32 -0400 Received: from [192.168.0.3] ([10.82.241.129]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 17:41:31 -0400 In-Reply-To: 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> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <186FA279-5A25-4F50-8CBA-57CD9FDAA925@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RRG] Re: [RAM] Tunneling overheads and fragmentation Date: Tue, 11 Sep 2007 14:41:31 -0700 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 11 Sep 2007 21:41:31.0834 (UTC) FILETIME=[848EF9A0:01C7F4BC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=546; t=1189546913; x=1190410913; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RRG]=20Re=3A=20[RAM]=20Tunneling=20overheads=20and=2 0fragmentation |Sender:=20 |To:=20Iljitsch=20van=20Beijnum=20; bh=n3lapV8yjD+Vh5TYhmJ48kCKoKRPCJmFB/EEC/kgPlo=; b=JEFau7VLnhqoi3yWH9Sir8WTYZlFIlgzlDpfWojtxx5l3C8AwcDx09FWqe4LnWRCPFEShuwI mmIio68BJcubBt0gfFEup6eu5Ppiuqm0sXQRrOdET/lOKzu/LRen1OyN; Authentication-Results: rtp-dkim-1; header.From=dino@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: RAM Mailing List , Robin Whittle X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > Granted, this is a fairly old box in a small network, but I don't > see anyone seriously claiming that ALL ISP networks support packets > larger than 1500 bytes on ALL their internal links (and also on > inter-ISP links). I did a survey about a month ago and it is true. I will yield to those folks who responded to me to protect their privacy. ;-) But the main gist was: o We are going to 9K MTUs on all our internal links. o Where we don't have 9K MTUs, we use 4470. o Virtually no one runs ISP links at 1500. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Sep 11 17:51:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVDdl-000699-RD; Tue, 11 Sep 2007 17:51:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVDdk-00065o-VB for ram@iab.org; Tue, 11 Sep 2007 17:51:24 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVDdj-0008AO-Kx for ram@iab.org; Tue, 11 Sep 2007 17:51:24 -0400 Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l8BLlPmx019806 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Sep 2007 23:47:25 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <186FA279-5A25-4F50-8CBA-57CD9FDAA925@cisco.com> 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> <186FA279-5A25-4F50-8CBA-57CD9FDAA925@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RRG] Re: [RAM] Tunneling overheads and fragmentation Date: Tue, 11 Sep 2007 23:49:55 +0200 To: Dino Farinacci X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: RAM Mailing List , Robin Whittle X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 11-sep-2007, at 23:41, Dino Farinacci wrote: >> Granted, this is a fairly old box in a small network, but I don't >> see anyone seriously claiming that ALL ISP networks support >> packets larger than 1500 bytes on ALL their internal links (and >> also on inter-ISP links). > I did a survey about a month ago and it is true. I will yield to > those folks who responded to me to protect their privacy. ;-) > But the main gist was: > o We are going to 9K MTUs on all our internal links. > o Where we don't have 9K MTUs, we use 4470. > o Virtually no one runs ISP links at 1500. That's good news, because then we can apparently treat anyone using 1500 as an exception that can be dealt with operationally rather than something that must be addressed in the protocol. 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. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Sep 11 17:53:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVDgA-00008m-Ev; Tue, 11 Sep 2007 17:53:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVDg9-00008f-27 for ram@iab.org; Tue, 11 Sep 2007 17:53:53 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVDg7-0008CL-E0 for ram@iab.org; Tue, 11 Sep 2007 17:53:53 -0400 X-IronPort-AV: E=Sophos;i="4.20,240,1186372800"; d="scan'208";a="131671564" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 11 Sep 2007 17:53:48 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8BLrpFW025082; Tue, 11 Sep 2007 17:53:51 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8BLroE0023470; Tue, 11 Sep 2007 21:53:50 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 17:53:50 -0400 Received: from [192.168.0.3] ([10.82.241.129]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 17:53:49 -0400 In-Reply-To: <186FA279-5A25-4F50-8CBA-57CD9FDAA925@cisco.com> 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> <186FA279-5A25-4F50-8CBA-57CD9FDAA925@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4FC2075B-2E11-4C0F-A5CC-0ABAB75E826C@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RRG] Re: [RAM] Tunneling overheads and fragmentation Date: Tue, 11 Sep 2007 14:53:50 -0700 To: Dino Farinacci X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 11 Sep 2007 21:53:49.0865 (UTC) FILETIME=[3C759190:01C7F4BE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1533; t=1189547631; x=1190411631; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RRG]=20Re=3A=20[RAM]=20Tunneling=20overheads=20and=2 0fragmentation |Sender:=20 |To:=20Dino=20Farinacci=20; bh=KH4MuXMnmqQqTgchhFIBXgN8hEA6QYgT5Ahip86N2s8=; b=oErcNVAn7hpUBikoKW2D5Ohl3iBk5PGVkFHkkJW1a8X6CeVOPixZ+lRYQmSg1X8RBCK9Vzhr mjqhm/yyLEOVfc2ehacjTWZgejJhOZvy87LS52FIz/J9aq6FAfNnKdGA; Authentication-Results: rtp-dkim-1; header.From=dino@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Robin Whittle , RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >> Granted, this is a fairly old box in a small network, but I don't >> see anyone seriously claiming that ALL ISP networks support >> packets larger than 1500 bytes on ALL their internal links (and >> also on inter-ISP links). > > I did a survey about a month ago and it is true. I will yield to > those folks who responded to me to protect their privacy. ;-) > > But the main gist was: > > o We are going to 9K MTUs on all our internal links. > o Where we don't have 9K MTUs, we use 4470. > o Virtually no one runs ISP links at 1500. And hence why I put this paragraph (the second one below) in section 5 of draft-farinacci-lisp-03.txt to reflect Brian Carpenter's comment on the subject: ----- Since additional tunnel headers are prepended, the packet becomes larger and in theory can exceed the MTU of any link traversed from the ITR to the ETR. It is recommended, in IPv4 that packets do not get fragmented as they are encapsulated by the ITR. Instead, the packet is dropped and an ICMP Too Big message is returned to the source. In practice, this is not really a problem. Hosts typically do not originate IP packets larger than 1500 bytes. And second, a survey has been taken (from a list of ISPs, see Acknowledgement section) where nearly all ISP link MTUs are either 4470 bytes or support Ethernet jumbo frames of 9000 bytes. Therefore, we don't anticipate any problems with prepending additional headers. ----- Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Sep 11 17:54:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVDh2-0000wt-KI; Tue, 11 Sep 2007 17:54:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVDh1-0000wo-5s for ram@iab.org; Tue, 11 Sep 2007 17:54:47 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVDh0-0008D1-0j for ram@iab.org; Tue, 11 Sep 2007 17:54:47 -0400 X-IronPort-AV: E=Sophos;i="4.20,240,1186372800"; d="scan'208";a="131671608" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 11 Sep 2007 17:54:43 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8BLsjXe025584; Tue, 11 Sep 2007 17:54:45 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8BLsjBY012222; Tue, 11 Sep 2007 21:54:45 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 17:54:45 -0400 Received: from [192.168.0.3] ([10.82.241.129]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 17:54:44 -0400 In-Reply-To: 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> <186FA279-5A25-4F50-8CBA-57CD9FDAA925@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <78BE8AF3-82FC-4B47-A89A-F67704D89377@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RRG] Re: [RAM] Tunneling overheads and fragmentation Date: Tue, 11 Sep 2007 14:54:46 -0700 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 11 Sep 2007 21:54:45.0069 (UTC) FILETIME=[5D5D07D0:01C7F4BE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=439; t=1189547685; x=1190411685; 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 |Subject:=20Re=3A=20[RRG]=20Re=3A=20[RAM]=20Tunneling=20overheads=20and=2 0fragmentation |Sender:=20 |To:=20Iljitsch=20van=20Beijnum=20; bh=hMIzI/tacLFGohbMsd6o4l8Oq2U3S0nkX7ThSNqoF2I=; b=tqPa7eLiHM+pDIkSNP/duuqW5kS2xV+GcVEeY6gUqY6Zjp4ESUeLYVDOIS1ntjBRBO81rkS9 37d9Pwtjqln6kW8i+dUtaMIwW8GHdgH7xjSFoImCdApPacF7C2R1vimt; 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: 7bac9cb154eb5790ae3b2913587a40de Cc: RAM Mailing List , Robin Whittle X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > 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. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Sep 12 02:59:50 2007 Return-path: 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 (EEST) From: Pekka Savola To: Dino Farinacci Subject: Re: [RRG] Re: [RAM] Tunneling overheads and fragmentation In-Reply-To: <78BE8AF3-82FC-4B47-A89A-F67704D89377@cisco.com> Message-ID: 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> <186FA279-5A25-4F50-8CBA-57CD9FDAA925@cisco.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 , RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From ram-bounces@iab.org Wed Sep 12 10:25:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVT9F-0003yP-Bv; Wed, 12 Sep 2007 10:24:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVT9D-0003y8-UD for ram@iab.org; Wed, 12 Sep 2007 10:24:55 -0400 Received: from smtp1.extremenetworks.com ([207.179.9.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVT9C-00009Q-Kb for ram@iab.org; Wed, 12 Sep 2007 10:24:55 -0400 Received: from [10.30.20.61] (unknown [10.30.20.61]) by smtp1.extremenetworks.com (Postfix) with ESMTP id A91757947 for ; Wed, 12 Sep 2007 07:24:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <896E7873-B5D5-442E-AB33-63910A6E78BE@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ram@iab.org From: RJ Atkinson Date: Wed, 12 Sep 2007 10:24:52 -0400 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [RAM] Tunnelling & GigE jumbo frame size X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Dino's notes all sound correct, with one exception. The exception is a detail and does not alter his main point, which is that by using Jumbo Ethernet, tunnelling of 1518 byte Ethernet frames ought not create any fragmentation issues. However, just to be crystal clear to anyone who isn't tracking Ethernet closely, here is the summary analysis. Correction: Just as "4K" MTU really means 4470 bytes, Jumbo Ethernet sizes of "9K" really mean an IP MTU of 9180 bytes. This means the link MTU for Jumbo Ethernet is really: (9180 + sizeof(Ethernet header) + sizeof(VLAN tag)) Implementers who want to be more widely deployable will have a "9K" link MTU that allows for at least 2 VLAN tags (considering the widespread use of Q-in-Q encapsulation) or 1 VLAN tag plus 2 Ethernet MAC headers (for MAC-in-MAC encapsulation). Both Q-in-Q and MAC-in-MAC encapsulations are commonly used in Metro Service Provider deployments of Ethernet (e.g. in Japan, Korea, Sweden, and in the US). History: The Jumbo Ethernet 9K frame size was demanded by Ethernet users who were transitioning away from ATM/AAL5. So they wanted Jumbo Ethernet to support existing IP packet lengths for IP/ATM AAL5 [see RFC-1626] *without* any risk of IP fragmentation. Caveats: Jumbo Ethernet is explicitly not conformant to IEEE 802.3 standards. So all implementations that I'm aware of have a default MTU (i.e. out of the box) that is IEEE 802.3 compliant. Normally, users must explicitly configure the larger MTU size on each interface before it is enabled. 1 GigE standards permit deployment with CSMA/CD, although I am not personally aware of any such deployments. A GigE CSMA/CD deployment is likely not to work properly with an Ethernet frame size above that permitted by IEEE 802.3 standards. Switched Ethernet should be fine, however, and all actual 1 GigE deployments that I am aware of are switched and do not use CSMA/CD. Yours, Ran rja@extremenetworks.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Sep 12 12:43:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVVJU-0000CO-PK; Wed, 12 Sep 2007 12:43:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVVJT-00005T-R4 for ram@iab.org; Wed, 12 Sep 2007 12:43:39 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVVJS-0004AV-Aq for ram@iab.org; Wed, 12 Sep 2007 12:43:39 -0400 Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l8CGdaJX036676 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Sep 2007 18:39:36 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <896E7873-B5D5-442E-AB33-63910A6E78BE@extremenetworks.com> References: <896E7873-B5D5-442E-AB33-63910A6E78BE@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] Tunnelling & GigE jumbo frame size Date: Wed, 12 Sep 2007 18:42:06 +0200 To: RJ Atkinson X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 12-sep-2007, at 16:24, RJ Atkinson wrote: > Dino's notes all sound correct, with one exception. I'd like to support Pekka's point about internet exchanges, though. > The exception is a detail and does not alter his main point, > which is that by using Jumbo Ethernet, tunnelling > of 1518 byte Ethernet frames ought not create any > fragmentation issues. However, just to be crystal clear > to anyone who isn't tracking Ethernet closely, here > is the summary analysis. Please note that ethernet frame size / MTU may or may not include the Ethernet_II header (which doesn't conform to IEEE 802.3) and if it does, it may or may not include the frame check sequence. I'll use the IP MTU excluding ethernet headers unless otherwise specified. > Correction: > Just as "4K" MTU really means 4470 bytes, Jumbo Ethernet > sizes of "9K" really mean an IP MTU of 9180 bytes. This > means the link MTU for Jumbo Ethernet is really: > (9180 + sizeof(Ethernet header) + sizeof(VLAN tag)) I think most people take it to mean 9000 bytes. This is the only real jumboframe IP MTU size I've seen implemented in hosts. However, routers and especially switches come with many different maximum frame sizes. I've looked over some product literature and compiled the following list: 1508, 1530, 1536, 1546, 1998, 2000, 2018, 4464, 4470, 8092, 8192, 9000, 9176, 9180, 9216, 17976, 64000 and 65280. > Caveats: > Jumbo Ethernet is explicitly not conformant to IEEE 802.3 > standards. So all implementations that I'm aware of have > a default MTU (i.e. out of the box) that is IEEE 802.3 > compliant. Normally, users must explicitly configure the > larger MTU size on each interface before it is enabled. > 1 GigE standards permit deployment with CSMA/CD, although > I am not personally aware of any such deployments. A GigE > CSMA/CD deployment is likely not to work properly with > an Ethernet frame size above that permitted by IEEE 802.3 > standards. Switched Ethernet should be fine, however, > and all actual 1 GigE deployments that I am aware of are > switched and do not use CSMA/CD. When gigabit ethernet was introduced the _minimum_ frame size (not IP MTU size) was (sort of) increased from 64 to 512 bytes when using CSMA/CD to make sure a frame would fill the entire collision domain even at the faster bit rate. However, the _maximum_ frame size was never increased because it would break old stuff. Lots of gigabit ethernet equipment supports larger frames, but few 10 or 100 Mbps implementations do. So having a larger frame size for GigE would make interoperation with older ethernet equipment a problem. Although the issue comes up in the IEEE 802.3 working group every few years, no progress has been made here because the IEEE protocols simply don't have the hooks that make maximum frame size negotiation between ethernet systems possible. However, this is much easier at the IP level (especially IPv6), so I'm proposing that the IETF pick up the slack. See the discussion about my multi-mtu draft on the internet area list: http://www1.ietf.org/mail-archive/web/int-area/current/index.html _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Sep 12 13:43:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVWEx-0006rH-3z; Wed, 12 Sep 2007 13:43:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVWEv-0006r6-Hy for ram@iab.org; Wed, 12 Sep 2007 13:43:01 -0400 Received: from smtp1.extremenetworks.com ([207.179.9.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVWEu-0005Ct-AH for ram@iab.org; Wed, 12 Sep 2007 13:43:01 -0400 Received: from [10.30.20.61] (unknown [10.30.20.61]) by smtp1.extremenetworks.com (Postfix) with ESMTP id 6ADFD7946 for ; Wed, 12 Sep 2007 10:42:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <896E7873-B5D5-442E-AB33-63910A6E78BE@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1CD6EB92-9167-4EAE-B372-A517572FCA4D@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [RAM] Tunnelling & GigE jumbo frame size Date: Wed, 12 Sep 2007 13:42:58 -0400 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 12 Sep 2007, at 12:42, Iljitsch van Beijnum wrote: > On 12-sep-2007, at 16:24, RJ Atkinson wrote: >> Correction: >> Just as "4K" MTU really means 4470 bytes, Jumbo Ethernet >> sizes of "9K" really mean an IP MTU of 9180 bytes. This >> means the link MTU for Jumbo Ethernet is really: >> (9180 + sizeof(Ethernet header) + sizeof(VLAN tag)) > > I think most people take it to mean 9000 bytes. I strongly disagree -- speaking as someone who spends a lot of time talking with A LOT of different Ethernet end users around the world, including users with deployments on all continents. The origin for the requirement came from super-computing sites with ATM deployments, and they drove all the vendors in the same direction (and vendors that didn't comply with their definition lost potential business as a result; economics tends to win in such cases). > This is the only real jumboframe IP MTU size I've seen implemented > in hosts. You should look around more broadly then. I've seen the jumbo MTU that I outlined in multiple versions of UNIX and in other kinds of systems. Moreover, the jumbo MTU is primarily deployed by service providers and super-computer centers, and is not often used by ordinary end systems (e.g. one's home computer). I'm not current with MTU support in current Windows, but earlier versions of Windows did support more than 9000 bytes on Gigabit Ethernet. > However, routers and especially switches come with many different > maximum frame sizes. I've looked over some product literature and > compiled the following list: 1508, 1530, 1536, 1546, 1998, 2000, > 2018, 4464, 4470, 8092, 8192, 9000, 9176, 9180, 9216, 17976, 64000 > and 65280. As there is no standard, the maximum for a particular device will vary. Most networking devices make this parameter *configurable*, below some maximum value. Varying maxima was not the question on the table, however. The question on the table is *narrowly* "what is meant by 9K MTU ?". I stand by the contents of my original note. Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Sep 12 14:14:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVWjj-0007n7-NX; Wed, 12 Sep 2007 14:14:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVWji-0007n0-J6 for ram@iab.org; Wed, 12 Sep 2007 14:14:50 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVWjh-0006Cm-98 for ram@iab.org; Wed, 12 Sep 2007 14:14:50 -0400 Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l8CIAsTK038082 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Sep 2007 20:10:54 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <1CD6EB92-9167-4EAE-B372-A517572FCA4D@extremenetworks.com> References: <896E7873-B5D5-442E-AB33-63910A6E78BE@extremenetworks.com> <1CD6EB92-9167-4EAE-B372-A517572FCA4D@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] Tunnelling & GigE jumbo frame size Date: Wed, 12 Sep 2007 20:13:24 +0200 To: RJ Atkinson X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 12-sep-2007, at 19:42, RJ Atkinson wrote: >>> Just as "4K" MTU really means 4470 bytes, Jumbo Ethernet >>> sizes of "9K" really mean an IP MTU of 9180 bytes. This >>> means the link MTU for Jumbo Ethernet is really: >>> (9180 + sizeof(Ethernet header) + sizeof(VLAN tag)) >> I think most people take it to mean 9000 bytes. > I strongly disagree [...] >> This is the only real jumboframe IP MTU size I've seen implemented >> in hosts. > You should look around more broadly then. (Oh wait: I once saw a 10 Gbit ethernet card in a couple of PowerMac G5s that did 16384 bytes.) > I've seen the jumbo MTU that I outlined in multiple versions of UNIX > and in other kinds of systems. Moreover, the jumbo MTU is primarily > deployed by service providers and super-computer centers, and is > not often used by ordinary end systems (e.g. one's home computer). Let me make several points at once. This is my computer at home, a Mac laptop: $ sudo ifconfig en0 mtu 9180 Password: $ ifconfig en0 en0: flags=8863 mtu 1500 supported media: autoselect 10baseT/UTP 10baseT/UTP 10baseT/UTP 10baseT/UTP 100baseTX 100baseTX 100baseTX 100baseTX 1000baseT 1000baseT 1000baseT none $ sudo ifconfig en0 mtu 9000 $ ifconfig en0 en0: flags=8863 mtu 9000 $ ifconfig lo0 lo0: flags=8049 mtu 16384 In other words: it can do 9000 bytes but not 9180 and the default MTU on the loopback interface is 16834 so obviously 9000 is not a maximum imposed by the OS. And apparantly, it can't do half duplex for gigabit ethernet. >> However, routers and especially switches come with many different >> maximum frame sizes. I've looked over some product literature and >> compiled the following list: 1508, 1530, 1536, 1546, 1998, 2000, >> 2018, 4464, 4470, 8092, 8192, 9000, 9176, 9180, 9216, 17976, 64000 >> and 65280. > As there is no standard, the maximum for a particular device will > vary. > Most networking devices make this parameter *configurable*, below > some maximum value. Varying maxima was not the question on the table, > however. > The question on the table is *narrowly* "what is meant by 9K MTU ?". > I stand by the contents of my original note. Well obviously we shouldn't be saying "9k MTU" because it is too imprecise. Also, it's irrelevant unless we're trying to come up with a unified MTU size, which is something I am very much against, as it doesn't solve the problem but only moves the goalposts. We need to move to a situation where the capability to use larger packets is used where it exists and to the degree that it exists. If we can increase the average packet size used on the internet by transmitting the same amount of data in fewer packets and routers/ switches are built such that they mostly use power when they are actually doing work, this will help with the power/heat issue. But for the purposes of a jack up solution we just need a few dozen extra bytes to accommodate the new headers without triggering the breakage that ensues when 1500-byte packets can't be forwarded without fragmentation. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Sep 12 14:22:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVWqn-0000R2-0L; Wed, 12 Sep 2007 14:22:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVWqm-0000Kc-7l for ram@iab.org; Wed, 12 Sep 2007 14:22:08 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVWql-0006KL-1x for ram@iab.org; Wed, 12 Sep 2007 14:22:08 -0400 X-IronPort-AV: E=Sophos;i="4.20,245,1186372800"; d="scan'208";a="131750874" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 12 Sep 2007 14:22:07 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8CIM6eS029282; Wed, 12 Sep 2007 14:22:06 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8CILoBo009125; Wed, 12 Sep 2007 18:22:02 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Sep 2007 14:21:58 -0400 Received: from [192.168.0.3] ([10.82.208.19]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Sep 2007 14:21:57 -0400 In-Reply-To: References: <896E7873-B5D5-442E-AB33-63910A6E78BE@extremenetworks.com> <1CD6EB92-9167-4EAE-B372-A517572FCA4D@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Tunnelling & GigE jumbo frame size Date: Wed, 12 Sep 2007 11:22:00 -0700 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Sep 2007 18:21:57.0870 (UTC) FILETIME=[CDEED0E0:01C7F569] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=589; t=1189621326; x=1190485326; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20Tunnelling=20&=20GigE=20jumbo=20frame=20size |Sender:=20 |To:=20Iljitsch=20van=20Beijnum=20; bh=asFxZCkxDPw7okFeB1Y2VSQb6Rdofu/uOEahPVYx4i8=; b=mjvLgubGlR710WG/n8AqSt5tGZVS1UFr4JipB/OORudhAZwu8prxR5r4TGXaUeJDucewX2RX 540kOiArR27n+NeyBjZVR4gP0QDbMwCVxaK1Lg2MzcQAvdESYuezxiDy; Authentication-Results: rtp-dkim-1; header.From=dino@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > Well obviously we shouldn't be saying "9k MTU" because it is too > imprecise. Also, it's irrelevant unless we're trying to come up > with a unified MTU size, which is something I am very much against, > as it doesn't solve the problem but only moves the goalposts. We > need to move to a situation where the capability to use larger > packets is used where it exists and to the degree that it exists. I will change the reference in the LISP spec from "jumbo frames of 9000 bytes" to "jumbo frames of 9180 bytes". Will be reflected in the next ID update. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Sep 12 14:34:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVX36-0001Ur-VP; Wed, 12 Sep 2007 14:34:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVX35-0001Tc-N2 for ram@iab.org; Wed, 12 Sep 2007 14:34:51 -0400 Received: from smtp1.extremenetworks.com ([207.179.9.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVX34-0006cB-Fh for ram@iab.org; Wed, 12 Sep 2007 14:34:51 -0400 Received: from [10.30.20.61] (unknown [10.30.20.61]) by smtp1.extremenetworks.com (Postfix) with ESMTP id 45C557946 for ; Wed, 12 Sep 2007 11:34:46 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <896E7873-B5D5-442E-AB33-63910A6E78BE@extremenetworks.com> <1CD6EB92-9167-4EAE-B372-A517572FCA4D@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <45779BAC-34BD-49ED-A924-05DF4666FCC6@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [RAM] Tunnelling & GigE jumbo frame size Date: Wed, 12 Sep 2007 14:34:45 -0400 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 12 Sep 2007, at 14:13, Iljitsch van Beijnum wrote: > Let me make several points at once. This is my computer at home, > a Mac laptop: (A bunch of irrelevant stuff deleted here. What a Mac can or can't do isn't representative of anything beyond Apple, certainly not of the entire world.) > We need to move to a situation where the capability to use larger > packets is used where it exists and to the degree that it exists. I know of a LOT of metro SPs and ISPs and IXs that already support the 9180++ MTU that I outlined before -- in their operational network right now. I think NDAs do not permit me to enumerate the list that I know about personally...it isn't a short list in any event. > But for the purposes of a jack up solution we just need a few dozen > extra bytes to accommodate the new headers without triggering the > breakage that ensues when 1500-byte packets can't be forwarded > without fragmentation. If you believe the above, why have you been wasting everyone's time just now ? Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Sep 12 15:37:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVY1N-0003fE-8Y; Wed, 12 Sep 2007 15:37:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVY1L-0003f0-PD for ram@iab.org; Wed, 12 Sep 2007 15:37:07 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVY1K-00006l-EG for ram@iab.org; Wed, 12 Sep 2007 15:37:07 -0400 Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l8CJX8pD039476 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Sep 2007 21:33:15 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <45779BAC-34BD-49ED-A924-05DF4666FCC6@extremenetworks.com> References: <896E7873-B5D5-442E-AB33-63910A6E78BE@extremenetworks.com> <1CD6EB92-9167-4EAE-B372-A517572FCA4D@extremenetworks.com> <45779BAC-34BD-49ED-A924-05DF4666FCC6@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6EB2B436-9CA9-4636-802D-B2E64E3E1708@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] Tunnelling & GigE jumbo frame size Date: Wed, 12 Sep 2007 21:35:39 +0200 To: RJ Atkinson X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 12-sep-2007, at 20:34, RJ Atkinson wrote: >> We need to move to a situation where the capability to use larger >> packets is used where it exists and to the degree that it exists. > I know of a LOT of metro SPs and ISPs and IXs that already support > the 9180++ MTU that I outlined before Yes, but the way IP currently works means that ALL equipment in an IP subnet must share the same MTU. This is not a problem in itself if you have a homogonous ISP network (but the fact that you need to enable the larger size by hand is even there) but that requirement makes it extremely hard to deploy larger packet sizes in many other environments. >> But for the purposes of a jack up solution we just need a few >> dozen extra bytes to accommodate the new headers without >> triggering the breakage that ensues when 1500-byte packets can't >> be forwarded without fragmentation. > If you believe the above, why have you been wasting everyone's time > just now ? Does anyone believe anything else?? 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. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Sep 12 15:48:14 2007 Return-path: 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> <1CD6EB92-9167-4EAE-B372-A517572FCA4D@extremenetworks.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 Subject: Re: [RAM] Tunnelling & GigE jumbo frame size Date: Wed, 12 Sep 2007 12:47:58 -0700 To: Iljitsch van Beijnum 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 |Subject:=20Re=3A=20[RAM]=20Tunnelling=20&=20GigE=20jumbo=20frame=20size |Sender:=20 |To:=20Iljitsch=20van=20Beijnum=20; 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 , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From ram-bounces@iab.org Wed Sep 12 16:03:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVYQF-0005NU-AU; Wed, 12 Sep 2007 16:02:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVYQE-0005NP-1J for ram@iab.org; Wed, 12 Sep 2007 16:02:50 -0400 Received: from moebius2.space.net ([195.30.1.100]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IVYQC-0000eO-A7 for ram@iab.org; Wed, 12 Sep 2007 16:02:49 -0400 Received: (qmail 15557 invoked by uid 1007); 12 Sep 2007 20:02:47 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=EMcT0kF8UVQNdJ593Ps96G5nwerOY6gv7MnSNXhKxOxz2LecfJAfg4w3zV7fM9Ul ; Date: Wed, 12 Sep 2007 22:02:47 +0200 From: Gert Doering To: Dino Farinacci Subject: Re: [RAM] Tunnelling & GigE jumbo frame size Message-ID: <20070912200247.GR69215@Space.Net> References: <896E7873-B5D5-442E-AB33-63910A6E78BE@extremenetworks.com> <1CD6EB92-9167-4EAE-B372-A517572FCA4D@extremenetworks.com> <45779BAC-34BD-49ED-A924-05DF4666FCC6@extremenetworks.com> <6EB2B436-9CA9-4636-802D-B2E64E3E1708@muada.com> <2CBC95AD-E817-4A9A-ACDA-26597346B3F8@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2CBC95AD-E817-4A9A-ACDA-26597346B3F8@cisco.com> User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi, On Wed, Sep 12, 2007 at 12:47:58PM -0700, Dino Farinacci wrote: > 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. Where is this assumption coming from? As long as there are FastE links, this is not going to happen. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 122119 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Sep 12 16:07:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVYV2-0008LH-IR; Wed, 12 Sep 2007 16:07:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVYV1-0008LA-OA for ram@iab.org; Wed, 12 Sep 2007 16:07:47 -0400 Received: from smtp1.extremenetworks.com ([207.179.9.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVYV0-0000lV-GJ for ram@iab.org; Wed, 12 Sep 2007 16:07:47 -0400 Received: from [10.30.20.61] (unknown [10.30.20.61]) by smtp1.extremenetworks.com (Postfix) with ESMTP id DF4857946; Wed, 12 Sep 2007 13:07:41 -0700 (PDT) In-Reply-To: <20070912200247.GR69215@Space.Net> References: <896E7873-B5D5-442E-AB33-63910A6E78BE@extremenetworks.com> <1CD6EB92-9167-4EAE-B372-A517572FCA4D@extremenetworks.com> <45779BAC-34BD-49ED-A924-05DF4666FCC6@extremenetworks.com> <6EB2B436-9CA9-4636-802D-B2E64E3E1708@muada.com> <2CBC95AD-E817-4A9A-ACDA-26597346B3F8@cisco.com> <20070912200247.GR69215@Space.Net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <85049E70-CF6D-470C-8AAF-D2CD451AB995@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [RAM] Tunnelling & GigE jumbo frame size Date: Wed, 12 Sep 2007 16:07:41 -0400 To: Gert Doering X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 12 Sep 2007, at 16:02, Gert Doering wrote: > On Wed, Sep 12, 2007 at 12:47:58PM -0700, Dino Farinacci wrote: >> 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. > > Where is this assumption coming from? > As long as there are FastE links, this is not going to happen. Are you trying to say that you currently have deployed router-to-router links inside an ISP/IX with less than 4470 bytes of IP MTU ? Btw, at least some 100baseTX/FX switches/routers can support the 9180 IP MTU. So it is not necessarily the case that 100baseTX/FX implies a 1518 byte link MTU. Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Sep 12 16:08:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVYVu-000140-2v; Wed, 12 Sep 2007 16:08:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVYVr-0000sZ-VS for ram@iab.org; Wed, 12 Sep 2007 16:08:39 -0400 Received: from moebius2.space.net ([195.30.1.100]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IVYVq-0000mI-LS for ram@iab.org; Wed, 12 Sep 2007 16:08:39 -0400 Received: (qmail 20180 invoked by uid 1007); 12 Sep 2007 20:08:37 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=XapwPJAl0BovOwxBf3YsY18fUPutp0dkM/nwXlMFAjDg9gEpGOkdQNEUaA/Vv0zi ; Date: Wed, 12 Sep 2007 22:08:37 +0200 From: Gert Doering To: Dino Farinacci Subject: Re: [RRG] Re: [RAM] Tunneling overheads and fragmentation Message-ID: <20070912200837.GS69215@Space.Net> 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> <186FA279-5A25-4F50-8CBA-57CD9FDAA925@cisco.com> <4FC2075B-2E11-4C0F-A5CC-0ABAB75E826C@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FC2075B-2E11-4C0F-A5CC-0ABAB75E826C@cisco.com> User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Robin Whittle , RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi, I seem to have missed that e-mail. Sorry for replying not in sequence. On Tue, Sep 11, 2007 at 02:53:50PM -0700, Dino Farinacci wrote: > >I did a survey about a month ago and it is true. I will yield to > >those folks who responded to me to protect their privacy. ;-) We haven't been asked in this survey - and our data looks quite different. > >o We are going to 9K MTUs on all our internal links. > >o Where we don't have 9K MTUs, we use 4470. > >o Virtually no one runs ISP links at 1500. In nearly all locations we have devices that still have Fast Ethernet links (because upgrading to GigE is expensive and the amount of packes flowing through the link doesn't require it). While we don't run 1500 on links where MPLS is used, most Cisco gear in use cannot go over 1520...1530 on FastEthernet ports. This limits the GigE machines to 1530 as well, as things really break (today) if you share a layer2 segment between machines with different MTUs. So there is no way our network could run on a MTU of 4470 or even higher any time soon. [..] > In practice, this is not really a problem. Hosts typically do not > originate IP packets larger than 1500 bytes. And second, a survey > has been taken (from a list of ISPs, see Acknowledgement section) > where nearly all ISP link MTUs are either 4470 bytes or support > Ethernet jumbo frames of 9000 bytes. Therefore, we don't anticipate > any problems with prepending additional headers. This is handwaving, and not a good basis for research work. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 122119 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Sep 12 16:11:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVYYR-0007lO-6X; Wed, 12 Sep 2007 16:11:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVYYQ-0007l5-0z for ram@iab.org; Wed, 12 Sep 2007 16:11:18 -0400 Received: from moebius2.space.net ([195.30.1.100]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IVYYO-0000pK-Ae for ram@iab.org; Wed, 12 Sep 2007 16:11:17 -0400 Received: (qmail 24677 invoked by uid 1007); 12 Sep 2007 20:11:15 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=s4aXSJAa0w6XgY8VqeErMgaSszi2BCX3j07mg20kZKTZ5EvBzmGZjPJ/fgsuU1Fr ; Date: Wed, 12 Sep 2007 22:11:15 +0200 From: Gert Doering To: Dino Farinacci Subject: Re: [RRG] Re: [RAM] Tunneling overheads and fragmentation Message-ID: <20070912201115.GT69215@Space.Net> 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> <186FA279-5A25-4F50-8CBA-57CD9FDAA925@cisco.com> <78BE8AF3-82FC-4B47-A89A-F67704D89377@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78BE8AF3-82FC-4B47-A89A-F67704D89377@cisco.com> User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Robin Whittle , RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi, On Tue, Sep 11, 2007 at 02:54:46PM -0700, 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. You might be. We're not. At the DECIX, currently the 3rd biggest exchange in Europe, about one third of the members (all sharing a common L2 network!) are still connected with 100 Mbit/s. Which means "1500 for all of them". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 122119 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Sep 12 16:14:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVYbv-0000nu-6f; Wed, 12 Sep 2007 16:14:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVYbu-0000ng-An for ram@iab.org; Wed, 12 Sep 2007 16:14:54 -0400 Received: from moebius2.space.net ([195.30.1.100]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IVYbt-0000tH-0Q for ram@iab.org; Wed, 12 Sep 2007 16:14:54 -0400 Received: (qmail 24947 invoked by uid 1007); 12 Sep 2007 20:14:52 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=tb2sFVd1oZ3Obx+SB2W/wAHa3KkvrX7TNoRAnjJOL8QtdFPkO3t7azPrKhTVzlUT ; Date: Wed, 12 Sep 2007 22:14:52 +0200 From: Gert Doering To: RJ Atkinson Subject: Re: [RAM] Tunnelling & GigE jumbo frame size Message-ID: <20070912201452.GU69215@Space.Net> References: <896E7873-B5D5-442E-AB33-63910A6E78BE@extremenetworks.com> <1CD6EB92-9167-4EAE-B372-A517572FCA4D@extremenetworks.com> <45779BAC-34BD-49ED-A924-05DF4666FCC6@extremenetworks.com> <6EB2B436-9CA9-4636-802D-B2E64E3E1708@muada.com> <2CBC95AD-E817-4A9A-ACDA-26597346B3F8@cisco.com> <20070912200247.GR69215@Space.Net> <85049E70-CF6D-470C-8AAF-D2CD451AB995@extremenetworks.com> Mime-Version: 1.0 In-Reply-To: <85049E70-CF6D-470C-8AAF-D2CD451AB995@extremenetworks.com> User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0524975477==" Errors-To: ram-bounces@iab.org --===============0524975477== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lahf4aOtwRM/4oBY" Content-Disposition: inline --lahf4aOtwRM/4oBY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Sep 12, 2007 at 04:07:41PM -0400, RJ Atkinson wrote: > >>o All router-to-router links on the downstream side of an ITR use > >>either 4470 or 9180 byte MTUs. > > > >Where is this assumption coming from? > >As long as there are FastE links, this is not going to happen. >=20 > Are you trying to say that you currently have deployed > router-to-router links inside an ISP/IX with less than > 4470 bytes of IP MTU ? We have no single ethernet link in our network that has a MTU *above* 1530 (there are some that could be cranked up, but there was no need yet) I have a large number of links that have a MTU of *exactly* 1500 (because there is equipment that cannot handle 1530). All exchange points that we're connected to run the fabric at 1500 byte MTU, because they have members that have equipment that cannot handle more. There are *some* IXPs that have two different LANs, one with 1500 and one with "Jumbo", but that's not very widespread yet. So: the answer is "yes". > Btw, at least some 100baseTX/FX switches/routers can > support the 9180 IP MTU. So it is not necessarily > the case that 100baseTX/FX implies a 1518 byte link MTU. Switches are easy. Routers are not. What good is having a Jumbo-capable switch if there is one peer on the shared fabric that can only receive 1500-byte (+ Ethernet header) packets? Gert Doering -- NetMaster --=20 Total number of prefixes smaller than registry allocations: 122119 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --lahf4aOtwRM/4oBY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iQCVAwUBRuhIvKkuBuNlUUl1AQLaOAQAhLanyI5XDVy9Qy6eq+wXqIMdfUMifCPJ U9D8AVn1y/5V1NYMe2iV3LDD0j8e3y6GC6o3dLMjc6jvD/0SPgKS8AOATAaMzMq2 apvpsYCg4BbAY4zlcV5ODtm1xoDJ9HWdO1jJTqELR05xX3c+eM3jVtdZ4Vt9fZLX f1kGz8MKcoA= =M6z2 -----END PGP SIGNATURE----- --lahf4aOtwRM/4oBY-- --===============0524975477== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============0524975477==-- From ram-bounces@iab.org Wed Sep 12 21:58:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVdyO-000369-Em; Wed, 12 Sep 2007 21:58:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVdyM-0002zQ-S4 for ram@iab.org; Wed, 12 Sep 2007 21:58:26 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVdyL-0007BP-Kw for ram@iab.org; Wed, 12 Sep 2007 21:58:26 -0400 X-IronPort-AV: E=Sophos;i="4.20,247,1186383600"; d="scan'208";a="217142672" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 12 Sep 2007 18:58:21 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8D1wKqK009154; Wed, 12 Sep 2007 18:58:21 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l8D1wE3A028678; Thu, 13 Sep 2007 01:58:20 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Sep 2007 18:58:17 -0700 Received: from [171.71.55.174] ([171.71.55.174]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Sep 2007 18:58:17 -0700 In-Reply-To: <20070912200837.GS69215@Space.Net> 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> <186FA279-5A25-4F50-8CBA-57CD9FDAA925@cisco.com> <4FC2075B-2E11-4C0F-A5CC-0ABAB75E826C@cisco.com> <20070912200837.GS69215@Space.Net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <10EE8715-0232-43A7-9919-F50836F4FAE5@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RRG] Re: [RAM] Tunneling overheads and fragmentation Date: Wed, 12 Sep 2007 18:58:18 -0700 To: Gert Doering X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 13 Sep 2007 01:58:17.0193 (UTC) FILETIME=[8D47F590:01C7F5A9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=785; t=1189648701; x=1190512701; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RRG]=20Re=3A=20[RAM]=20Tunneling=20overheads=20and=2 0fragmentation |Sender:=20; bh=vkely71AvtEKu+o9hxLtNjstJCkcvrTV33ZkrMg+ots=; b=CxDzJ++qHEZdvZ2qrcDqHC8JJje9B+yW8otDis92QmXDeXYH2V0xoN6wm0+jWAtV2BeS1tCd zpkEdI1dLPOnTuZPxFs51CzsHNN4n3tklgsYyY0mjUwfdGv/wHCe1xev; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Robin Whittle , RAM Mailing List X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > So there is no way our network could run on a MTU of 4470 or even > higher any time soon. Then you don't deploy ITRs or you deploy fragmenting-ITRs. > [..] >> In practice, this is not really a problem. Hosts typically do not >> originate IP packets larger than 1500 bytes. And second, a survey >> has been taken (from a list of ISPs, see Acknowledgement section) >> where nearly all ISP link MTUs are either 4470 bytes or support >> Ethernet jumbo frames of 9000 bytes. Therefore, we don't >> anticipate >> any problems with prepending additional headers. > > This is handwaving, and not a good basis for research work. You are right, we are trying to make a decision and are doing engineering now past the research stage. ;-) Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram