[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [RRG] A data point on transit MTU size
Hi Brian,
>-----Original Message-----
>From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
>Sent: Tuesday, September 23, 2008 2:32 PM
>To: Templin, Fred L
>Cc: Dino Farinacci; RRG
>Subject: Re: [RRG] A data point on transit MTU size
>
>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.
This is in fact the very principle employed by SEAL, i.e.,
it is OK to do *outer* fragmentation even if the *inner*
packet has DF=1, because it is the ETR and not the final
destination that has to reassemble. (The final destination
therefore gets the inner packet in its original form.)
However, LISP talks about fragmenting the *inner* packet
(even if DF=1) before encapsulating as two *outer* packets,
in which case it is the final destination that gets to
reassemble. (But, the LISP ITR cannot know the size of
the final destination's reassembly buffer, nor whether
the final destination is even capable of reassembly.)
>>>> 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.
But, LISP does not propose reassembly at the ETR; it
proposes reassembly at the final destination and with
no coordination from the ITR.
>I don't have an opinion whether SEAL is necessary for that, or
>whether LISP can just rely on basic frag.
Hopefully from the above it can be seen that basic frag
per the LISP spec is optimistic at best and potentially
dangerous as well.
Fred
fred.l.templin@boeing.com
>
> 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