Re: [v6ops] 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.

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
> 