[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [RRG] Re: LISP PMTU & fragmentation problems
Dino,
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
fred.l.templin@boeing.com
>-----Original Message-----
>From: Dino Farinacci [mailto:dino@cisco.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
>> PMTU.
>
>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
>> jumboframe
>> 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
>that xTRs
>be placed on CE (CPE) routers. We think that is the best balance of
>tradeoffs.
>
>> 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
>site-facing
>>> 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
>> ETR.
>> 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,
>then the
>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,
>>> and
>>> 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.
>
>Dino
>
>--
>to unsubscribe send a message to rrg-request@psg.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
>
--
to unsubscribe send a message to rrg-request@psg.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