[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
Call it what you wish, but we are trying to be practical and simple at
the same time. You know we really want to deploy this and not just
create paper with all kinds of protocol machinery just for the sake of
solving problems. Some problems don't need to be solved. Some problems
are not real problems.
the splitting for IPv4 packets that had DF=0 from the
original host, and there really aren't very many of those
So if you say DF=0 is non existent, then we say that small MTU links
are non-existent as well.
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
Well, sorry it's the real effective MTU, 1464 that is. And why is this
surprising?
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.
The MTU discovery will be contained inside of the site. That is a lot
better than all the way to the destination host.
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.
Too much machinery, it is not needed and we want to be stateless. Do
you not agree that our proposal is even simpler than SEAL?
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