Re: [lisp] looking for clarifications on rfc 6830

[Dino Farinacci <[e-mail]>]

> 2.Fragment size:
>> 
>> Page 21, Section 5.4.1
>> 
>> The size of the encapsulated fragments is then (S/2 + H), which is less
>> than the ITR's estimate of the path MTU between the ITR and its
>> correspondent ETR.
>> 
>> Is this right?
>> 
>> Look! H is a fixed number (= UDP header length + LISP header length),
>> and S is also a fixed size (= L – H, where L is the path MTU).
>> 
>> It looks to me that the fragment size should be less than (S/2+H).
>> 
>> In order to achieve (S/2+H), does the spec actually suggest any padding
>> so as to meet (S/2+H)?
> 
> There is a bit of sloppy wording.  The S in (S/2 + H) is not the maximum S supportable without fragmentation, but the actual size packet received from the site.  When we revise this document, we should clean up the description to make it more clear.

Please let me clarify. “L” is the largest packet an ITR can send so there is no fragmentation. So it is made up size H, the size of the headers the ITR will prepend, and S, the size of the packet that is offered by the source. S is the maximum that the source can send so that when H is added we can get L.

This is all stated in the 1-3 bullets.

The S/2 + H is the intentional size. We were not trying to get the maximum size packets for fragmentation because the intermediate routers could add headers (if there was more tunneling going on). So we give the intermediate routers S/2 room.

Dino