Fred, On 2008-09-24 03:25, Templin, Fred L wrote: > > >> -----Original Message----- >> From: Dino Farinacci [mailto:[EMAIL PROTECTED] >> 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:[EMAIL PROTECTED] >>>> 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 > [EMAIL PROTECTED] > >> Dino >> >>> >>> Fred >>> [EMAIL PROTECTED] >>> >>>> 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
