Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-05.txt

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

Hi Joe,

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Thursday, May 31, 2012 10:57 AM
> To: Templin, Fred L
> Cc: [e-mail]
> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-
> 05.txt
> 
> 
> 
> On 5/31/2012 10:47 AM, Templin, Fred L wrote:
> > Hi Joe,
> >
> >> -----Original Message-----
> >> From: Joe Touch [mailto:[e-mail]]
> >> Sent: Thursday, May 31, 2012 9:59 AM
> >> To: Templin, Fred L
> >> Cc: [e-mail]; [e-mail]; [e-mail]
> >> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-
> >> 05.txt
> ...
> >> That would change things by a factor of 2.
> ...
> > A 2X performance increase is not insignificant. And,
> > there seemed to be some interest for the use of IPv4
> > fragmentation for IPv4-over-IPv* tunnels.
> 
> Perhaps for other uses - as you note - but not to the discussions that
> are the focus of this draft. Which is why, IMO, it should be the focus
> of a different doc.

As you know, the bar for documents that would update
bedrock specifications such as RFC791 and RFC1122 is
set very high indeed. That your document has made it
to this level of maturation is a tribute to your many
years of concerted effort, which would best be amortized
if this useful addition can also be applied.

> >> - reducing the timeout is not current practice AFAIK
> >> 	so we'd be adding a new recommendation, rather
> >> 	than even documenting existing practice
> >>
> >> - my conclusion, based on "keep it simple", is to not include this
> >> recommendation in this document
> >
> > Let me ask, do you know of any implementations that have
> > ever benefitted from keeping the fragments of an incomplete
> > reassembly for longer than 60sec? (Linux for example only
> > waits 30sec before discarding fragments.)
> 
> I don't, but that's a discussion that should happen - as you note below
> - involving those on a different list as well, for a different reason.
> Linux does a lot of things that are not standard, but that alone is not
> necessarily a reason to document it as best practice - e.g., why are you
> not suggesting 30 sec?

60sec is consistent with both RFC1122 and RFC2460.

> >> If others disagree, they should speak up.
> >
> > This has implications for IPv4-over-IPv* tunnels,
> > which have been discussed on the v6ops list recently.
> 
> Perhaps, but only as a factor of 2 improvement, and you're raising a
> change that is new.
> 
> Again, since this is for a different motivation and because it's not
> documenting existing widespread practice, this seems appropriate for a
> separate document.

As above.
 
> >> ...
> >>>>>> Also, in the document's introduction, it says:
> >>>>>>
> >>>>>>     "In IPv4, the Identification (ID) field is a 16-bit value that
> is
> >>>>>>     unique for every datagram for a given source address,
> destination
> >>>>>>     address, and protocol, such that it does not repeat within the
> >>>>>>     Maximum Segment Lifetime (MSL) [RFC791][RFC1122]."
> >>>>>>
> >>>>> Isn't the correct reference for MSL actually RFC793?
> >>>>
> >>>> Yes; that should read "maximum datagram lifetime" as per RFC 791. I
> can
> >>>> fix that in AUTH48. Thanks,
> >>>
> >>> Maximum datagram lifetime per RFC791 doesn't talk about
> >>> the 120sec that your document discusses; Maximum Segment
> >>> Lifetime per RFC793 is the one that talks about 120sec.
> >>> If you want to talk about 120sec and MSL, you need to
> >>> cite RFC793 instead of RFC791.
> >>
> >> Segments aren't datagrams. RFC793 talks about segment lifetimes.
> RFC1122
> >> is the only one that talks about datagram lifetimes, relating the
> >> lifetime described in 791 to 120 seconds.
> >>
> >> I.e., the references are correct, but the term should be "maximum
> >> datagram lifetime", not "maximum segment lifetime". There is certainly
> a
> >> historical note that the 120 seconds in RFC1122 is likely related to
> >> RFC793, but that's conjecture - 1122 Sec 3.3.2 states that the lifetime
> >> should be between 60 and 120 seconds, and recommends 120 seconds
> without
> >> reference to 793.
> >
> > That's not how I read the discussion beginning at the
> > bottom of P. 57 of RFC1122. In my read, that text clearly
> > points to the 120sec as being derived from the TCP MSL
> > specification.
> 
> The top of page 58 refers to TCP MSL (page 57 does not).

I said: "beginning at the bottom of P.57". "Beginning"
means "start there and read further".

> And even if it
> refers to 793 as one component in the derivation of the recommendation
> in 1122, it is still 1122 that should be cited, not 793, IMO.

If you want to call it MSL you need to cite RFC793. If
you want to change all occurrences of MSL to something
else, then you could get away with citing only RFC1122.
My preference would be to keep it as MSL and cite RFC793.

Thanks - Fred
[e-mail]


> 
> JOe