Re: [RRG] A data point on transit MTU size

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

Fred,

On 2008-09-24 03:25, Templin, Fred L wrote:
>  
> 
>> -----Original Message-----
>> From: Dino Farinacci [mailto:dino@cisco.com] 
>> Sent: Tuesday, September 23, 2008 8:11 AM
>> To: Templin, Fred L
>> Cc: Brian E Carpenter; RRG
>> Subject: Re: [RRG] A data point on transit MTU size
>>
>>>> -----Original Message-----
>>>> From: Dino Farinacci [mailto:dino@cisco.com]
>>>> Sent: Monday, September 22, 2008 3:13 PM
>>>> To: Brian E Carpenter
>>>> Cc: RRG
>>>> Subject: Re: [RRG] A data point on transit MTU size
>>>>
>>>>> We've argued here about whether it's reasonable to assume 
>>> 1500 byte 
>>>>> MTU on transit links, when running a LISP-type solution.
>>>> And if the assumption doesn't hold, then you fragment before 
>>>> encapsulate. That is specified in the main LISP spec.
>>> 1) You can't use IPv4 fragmentation if DF=1.
>> Well, you could.
> 
> And break RFC791?

Why would DF be set on the outer (LISP-generated) header?
LISP can simply forbid that by specification.

It's irrelevant whether DF is set on the inner (end-host-generated)
header. LISP is acting as a layer 2 as far as that header is concerned.
There's no violation of 791, since the packet will be reassembled
before it's decapsulated.

> 
>>> 2) You can't send at high data rates if you use
>>>   IPv4 fragmentation.
>> Yes, you can. That is implementation dependent.
> 
> But sub-optimal implementations risk data corruption, which
> could be very bad.

Yes, we agree that sub-optimal implementations are a bad idea.
We also agree, I trust, that writing perfect reassembly code
is fairly hard (although I speak from 20 year old experience).
In particular the RFC 4459 and 4963 issues have to be handled.
I don't have an opinion whether SEAL is necessary for that,
or whether LISP can just rely on basic frag.

   Brian
> 
>>> IMHO, LISP should be SEALed. I will be here and ready to 
>> talk about it 
>>> whenever you are.
>> There is no reason to change our position.
> 
> In the lisp-interest archives, it was shown how incorporation
> of SEAL into LISP would in fact be better from an efficiency
> standpoint in that the header size remains the same plus you
> gain 6 additional Locator Reach Bits. That is in addition
> to the advantage that the path MTU issues are put to rest.
> 
>> Bigger fish to fry,
> 
> Eh?
> 
> Fred
> fred.l.templin@boeing.com
> 
>> Dino
>>
>>>
>>> Fred
>>> fred.l.templin@boeing.com
>>>
>>>> Dino
>>>>
>>>>> Here's a data point about the real world, as far as Internet
>>>> exchange
>>>>> points at the southern end go:
>>>>>
>>>>>
>> http://list.waikato.ac.nz/pipermail/nznog/2008-September/014471.html
>>>>>   Brian
>>>>>
>>>>> --
>>>>> 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
>>>>
>>
> 

--
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