>-----Original Message----- >From: Robin Whittle [mailto:[EMAIL PROTECTED] >Sent: Monday, July 28, 2008 4:54 PM >To: Routing Research Group; Routing Research Group >Cc: Pekka Savola >Subject: [RRG] Map-encap, fragmentation, PMTUD etc. > >I haven't been keeping up with the list of late, but noticed this >message, in the "Re: [RRG] Six/One Router Design Clarifications" >thread. Quoting Pekka, Tony wrote: > >> |As a result for encap/decap schemes I specifically want to see >> |how they 100% avoid fragmentation, or describe how they deal with >> |it. >> >> Cue Fred. ;-) > > http://tools.ietf.org/html/draft-templin-seal-22
Also the Linux kernel code is here: http://osprey67.com/seal To Pekka's question, fragmentation is not 100% avoided however it is "tuned out" as early as possible so as to avoid RFC4963-type problems (using a "report fragmentation" mechanism). >Please also take a look at: > > http://www.firstpr.com.au/ip/ivip/pmtud-frag/ > >My approach is intended to cope gracefully with transition to >jumboframes in the DFZ - so it goes well beyond coping with the >immediate problem of the encapsulation overhead pushing the final >packet length over the 1500 byte limit. I explain it in terms of >Ivip but I think the principles apply just as well to LISP, >APT or TRRP. SEAL also supports graceful accommodation of larger path MTUs. Just to be clear, the 2KB reassembly limit in SEAL is there *only* to accommodate paths with marginal MTUs. But, larger path MTUs will still be naturally discovered and utilized. Fred [EMAIL PROTECTED] > > - Robin > >-- >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
