Re: [v6ops] Prep for v6ops IETF 84 agenda

Hi Fred,

> -----Original Message-----
> From: Fred Baker (fred) [mailto:fred@cisco.com]
> Sent: Thursday, June 28, 2012 4:21 PM
> To: Templin, Fred L
> Cc: v6ops@ietf.org WG; Ron Bonica
> Subject: Re: Prep for v6ops IETF 84 agenda
> 
> 
> On Jun 29, 2012, at 12:34 AM, Templin, Fred L wrote:
> 
> >> -----Original Message-----
> >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of
> >> Fred Baker (fred)
> >> Sent: Sunday, June 24, 2012 7:05 PM
> >> To: v6ops@ietf.org WG
> >> Cc: Ron Bonica
> >> Subject: [v6ops] Prep for v6ops IETF 84 agenda
> >>
> >> I sat down this morning to assess our agenda. Interested in working
> group
> >> comment.
> >
> > OK Fred; I'll bite. Why are you listing 'draft-generic-v6ops-tunmtu'
> > as "#out of charter"?
> 
> Because changes to section 4.5 of RFC 2460 ("a source node may divide the
> packet...") is a change to RFC 2460, and should be discussed by the folks
> maintaining RFC 2460.

OK, I think I get your meaning now. You are concerned
that the draft in its current form seems to call for
an update to RFC2460 - right?

I'd like to propose a second alternative. Rather than
taking this over to 6man, my draft could be revised to
become a problem statement only rather than a functional
specification. Then, the fact that "(only) a source node
may divide the packet" becomes a problem to be addressed
in a different document - and not something to be defied
by this document.

Would you be willing to consider a new draft version
that stays within the problem statement narrative?

Thanks - Fred
fred.l.templin@boeing.com

> Begin forwarded message:
> 
> > From: "Fred Baker (fred)" <fred@cisco.com>
> > Date: June 23, 2012 5:43:22 AM GMT+08:00
> > To: Fred Templin <Fred.L.Templin@boeing.com>, "v6ops@ietf.org WG"
> <v6ops@ietf.org>
> > Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu
> >
> > Coming back to this as a meta-issue.
> >
> > v6ops is about operational considerations and procedures, but not
> protocols; disputing RFC 2460, aka redesigning IPv6, seems like a protocol
> issue.
> >
> > The reason to not do inner fragmentation, if memory serves, has to do
> with the behavior of fragmentation in the network and its effect on
> communications. For example, suppose you and I are in 9K clean networks
> (so the TCP MSS starts out as 9K), my link to the public network has an
> MTU of 1500, and somewhere en route to you there is another link with an
> MTU of 1400. When I send a 9K packet, it will become six 1500 byte packets
> with a small caboose that picks up the size of five IP headers (IPv4 or
> IPv6), and what you will receive is six 1400 byte packets interspersed
> with six 100+IP byte packets, followed by the original caboose. What if
> the fragmenting router's queue, at the time of fragmentation, was one
> packet short of the needed capacity? Maybe the retransmission follows a
> different path and is fragmented differently, resulting in funny overlaps
> whose handling isn't very well specified. There's nothing *incorrect*
> about a stream of 13 packets of various sizes being reassem
> > bled, but integrating retransmissions gets messy. IIRC, they just wanted
> to clean that up.
> >
> > Which brings me to the following consideration.
> >
> > If we're talking about having one tunnel endpoint put a message into a
> tunnel datagram and then fragment it, and have the other tunnel endpoint
> reassemble the original and forward it, we are talking about an
> operational procedure that requires support in a router, but which I can
> correlate with section 5 of RFC 2460.
> >
> > One thing I would invite is discussion of operational experience with
> RFC 4821. Wouldn't it be nice if the endpoint actually chose an MSS based
> on what actually worked (shades of Happy Eyeballs), rather than depending
> on error messages that network operators routinely filter out?
> >
> > If we're talking about changing the recommendation of RFC 2460 regarding
> who does fragmentation, that sounds like an IPv6 protocol change, and I'd
> like to refer that to 6MAN.
> >
> > Does that make sense?
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops