RE: "Deprecate"

["Templin, Fred L" <[e-mail]>]

Hi Mark,

> -----Original Message-----
> From: Mark Andrews [mailto:[e-mail]]
> Sent: Thursday, August 01, 2013 5:36 PM
> To: Templin, Fred L
> Cc: RJ Atkinson; [e-mail]
> Subject: Re: "Deprecate"
> 
> 
> In message <2134F8430051B64F815C691A62D983180DCA04@XCH-BLV-
> 504.nw.nos.boeing.co
> m>, "Templin, Fred L" writes:
> > Hi Ran,
> >
> > > Discussion:
> > >    Deployments using tunnels, whether IP-in-IP, GRE, IPsec tunnel-
> mode,
> > >    or some other IETF specified technology, are NOT going away.
> >
> > Yes, this is the same as I and others have been saying all along.
> >
> > > If the physical MTU is 1280, then the tunnel MTU will be smaller.
> >
> > Not allowed; the tunnel MUST be able to do a minimum 1280.
> >
> > >   Nested tunnels are not unusual and can be difficult to detect
> > >   absent a working PMTUD mechanism (whatever that might be).
> >
> > Agree that nested tunnels are not unusual and are in fact in
> > common widespread deployment. But, there is no need to "detect"
> > them from the source host's perspective as long as they honor
> > the IPv6 1280 minMTU. That means that tunnels MUST be prepared
> > to do a small amount of fragmentation and reassembly when
> > necessary.
> 
> And if we generate appoximately equal sized fragments rather than
> 1280 byte fragments + a runt fragment tunnels would need to fragment
> less often.  Your 1500 byte UDP payloads become 2 x 750 byte fragments
> which can be encapulated multiple times.

Yes, SEAL covers this in earlier document versions. "Approximately equal
length is what it used to say; now it says:

" breaks the inner packet into N non-overlapping segments (where N is
  minimized and each segment is significantly smaller than (MINMTU-HLEN)
  to allow for additional encapsulations in the path)."

but I can modify this to say: "in N approximately equal length
non-overlapping segments" to bring back what I had in earlier
versions.

Thanks - Fred
[e-mail]


> It doesn't take a lot of math to work out what size to fragment at to
> produce optimal fragment sizes for a given MTU.
> 
> Mark
> 
> > Thanks - Fred
> > [e-mail]
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]                 INTERNET: [e-mail]