Re: [v6ops] Prep for v6ops IETF 84 agenda

Fred,

> -----Original Message-----
> From: Fred Baker (fred) [mailto:fred@cisco.com]
> Sent: Monday, July 09, 2012 7:01 PM
> To: Templin, Fred L
> Cc: v6ops@ietf.org WG; Ron Bonica
> Subject: Re: Prep for v6ops IETF 84 agenda
> 
> No problem. Same rules apply as to all drafts; Joel and I will be looking
> for operational interest from the working group.

There was a lot of list discussion on this beginning
in mid-May and extending through the end of June, with
a considerable number of people involved.

Fred
fred.l.templin@boeing.com

> On Jul 9, 2012, at 5:07 PM, Templin, Fred L wrote:
> 
> > 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.
> >
> > This document has now been revised to speak only to
> > operational issues (and not any changes to RFC2460
> > nor any other documents):
> >
> > https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/
> >
> > Please re-review and re-evaluate in terms of charter
> > applicability.
> >
> > 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
> >