Hi Iljitsch, Responding to what you wrote in:
PMTUD, Sprite & IPTM; Outer src-addr = sending host's addr http://psg.com/lists/rrg/2007/msg00599.html and changing the subject line again . . . I would be delighted if you can show me it is practical to insist that ITRs and ETRs be installed only in places with significantly greater than 1500 byte MTU to the rest of the Net. As far as I know, it is impractical, due to the widespread use of 100Mbps links in many places. The quotes below from the RAM discussion on this, especially those from Gert Doering, seem to indicate that at present, there is sufficiently widespread use of 100Mbps Fast Ethernet, to drag down the MTU of many Internet exchange networks to 1500. I don't discount what you are saying. Maybe by the time an ITR-ETR scheme is introduced, it will be practical to insist on a minimum standard well above 1500. I hope some other people can contribute to this discussion. However, while it would be possible to configure an ITR in some way to tell it that it has a >>1500 byte MTU to the "core of the Net", this doesn't help much, since it can't know for sure that every ETR it needs to send packets to has a similarly high MTU. I think we need to have great flexibility in where ETRs are located, so I can't imagine it being practical to assume all ETRs have an MTU above 1500. Also, I think there are many benefits in having a caching ITR in the sending host, as I discuss below. Some messages on the RAM list concerning this are: http://www1.ietf.org/mail-archive/web/ram/current/msg01733.html Gert Doering: As of today, too many links and routers still have issues handling more than 1500 bytes of IP packets (like "most FastEthernet interfaces on Cisco routers", which is still considered "high bandwidth" over here). > What about routers in end-user networks, or CE routers of > providers? Even worse, due to DSL encapsulation you already end up with an IP MTU of 1492 bytes or less. http://www1.ietf.org/mail-archive/web/ram/current/msg01847.html http://www1.ietf.org/mail-archive/web/ram/current/msg01849.html Iljitsch van Beijnum: 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). 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. 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. http://www1.ietf.org/mail-archive/web/ram/current/msg01854.html Iljitsch van Beijnum: I think most people take it {jumboframes} 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. (More interesting stuff on the innards of Ethernet.) http://www1.ietf.org/mail-archive/web/ram/current/msg01861.html Gert Doering: 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. http://www1.ietf.org/mail-archive/web/ram/current/msg01862.html RJ Atkinson: 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. http://www1.ietf.org/mail-archive/web/ram/current/msg01863.html http://www1.ietf.org/mail-archive/web/ram/current/msg01864.html http://www1.ietf.org/mail-archive/web/ram/current/msg01865.html Gert Doering: In nearly all locations we have devices that still have Fast Ethernet links (because upgrading to GigE is expensive and the amount of packets 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. 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". RJ Atkinson wrote (in part): > 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? Regarding an ITR function in the sending host, this could be a really good use of free CPU and RAM resources, saving upstream dedicated ITRs from most of the work. I don't see any special security problems. Can you point out any specific problems? The only ITR-ETR scheme which allows for an ITR function in a sending host is Ivip: http://tools.ietf.org/html/draft-whittle-ivip-arch-00#section-1.7.3 The ITR function in a sending host needs to have fast, efficient, link to a nearby Query Server - so it would be a bad idea on dialup or on a link to an ISP which didn't have its own full database Query Server. - Robin -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
