[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[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