[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [RRG] Re: LISP PMTU & fragmentation problems
I have to agree that the new LISP text reads like a
"slacker's guide" to MTU handling. First, it only does
the splitting for IPv4 packets that had DF=0 from the
original host, and there really aren't very many of those
in-the-wild these days. Second, for IPv6 and IPv4 with DF=1,
the original source will be told a degenerate MTU that would
go against the principle of least surprise ("I expected 1500,
but only got 1464") plus it *always* results in packet loss
until MTU discovery has converged. Finally, there is no
provision for discovering MTUs larger than 1500 even though
the core may soon transition to all-GigE.
You have said that you believe the core is comprised almost
completely of links that can do quite a bit more than 1500.
Why not trust your judgement and just run SEAL; that way, you
get to enjoy the larger MTUs and will have no fragmentation
unless a degenerate link shows up on the path - in which case
SEAL will detect and correct it.
Thanks - Fred
>From: Dino Farinacci [mailto:email@example.com]
>Sent: Saturday, March 08, 2008 8:47 PM
>To: Robin Whittle
>Cc: Routing Research Group
>Subject: [RRG] Re: LISP PMTU & fragmentation problems
>> Short version: lisp-06's new material on Path MTU limits includes
>> some text on how to resolve the problems if they
>> are deemed to be bad enough to need a solution
>> within LISP. I can't understand this text in any
>> way which makes practical sense.
>Well, I'm sorry about that. The text is written in such simple and
>precise terms, I am surprised you wouldn't understand it.
>> Also, it would be good to publish the research
>> which indicates that 1500 byte MTU limits are
>> relatively rare.
>There wasn't research. It was a survey. I asked 10 people, and all 10
>made this statement. So there isn't much to publish.
>> If the problems of PMTU are deemed not worth
>> solving within LISP, then LISP would be deployed
>> on the assumption that all transit links would
>> be capable of some much higher than 1500 byte
>That is correct.
>> This would tend to constrain the locations of ITR
>> and ETR functions to be at or near border routers,
>> in order that they have unfettered access to
>> capable links to the core of the Internet.
>Right, or you do fragmentation. We did have an out.
>> This would seem to be a major restriction on the
>> ability of operators to place ITRs and ETRs wherever
>> they like.
>For Loc/ID purposes (there are several other reasons to use LISP than
>what is intended by this venue), we want to strongly suggest
>be placed on CE (CPE) routers. We think that is the best balance of
>> Likewise, it would seem to reduce the number of
>> devices which could do ITR or ETR functions and
>> thereby lead to bottlenecks and to these devices
>> needing to be large and expensive.
>No, not bottlenecks, easier deployability.
>You make it sound that by adding LISP to a router, it will get
>overloaded. You capacity design a router to deal with the input rate
>and density of the box and the amount of work you have to do. ITRs
>won't attract more traffic when they are at the CE. They get traffic
>based on who wants to send data to external destinations.
>> L = 1500
>> H = 36
>> S = 1464
>>> 1. Define an architectural constant S for the maximum size of a
>>> packet, in bytes, an ITR would receive from a source inside of
>>> its site.
>> S is 1464 bytes. But an ITR could receive a packet of any length
>> from a
>> source inside its site. So this sentence makes no proper
>sense to me.
>It means that if the packet from the source is >= 1464, the packet
>will be fragmented.
>>> When an ITR receives a packet of size greater than L on a
>>> interface and that packet needs to be encapsulated, it resolves the
>>> MTU issue by first splitting the original packet into 2 equal-sized
>>> fragments. A LISP header is then pre-pended to each fragment.
>> I guess you meant 'S' (1464) rather than 'L' (1500).
>The total packet size after the ITR is finished with it is L.
>> However, all this assumes that the ITR has a 1500 byte PMTU to the
>> In many cases, the PMTU will be a lot higher. So the above
>> algorithm does
>> not allow the ITR to send longer packets without fragmentation.
>That is correct. But maybe a source site that talks to a destination
>site of the same ISP that advertises support for larger MTUs,
>ITR be configured with an L value of 4470 or 9182 perhaps.
>> IPv6 or IPv4 with DF = 1
>>> ... the ITR will drop the packet when the size is greater than L,
>>> sends an ICMP Too Big message to the source with a value of S,
>>> where S
>>> is (L - H).
>> This makes no sense to me. It would make more sense if this
>> occurred when
>> the packet length was greater than S (1464 bytes for IPv4 or 1444
>> for IPv6).
>You want the ITR to tell the host to send a size so when the outer IP
>header, UDP header, and LISP header are prepended, the size of the
>packet is L.
>to unsubscribe send a message to firstname.lastname@example.org 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
to unsubscribe send a message to email@example.com 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