RE: 6MAN WG Last Call: <draft-ietf-6man-oversized-header-chain-04>

["George, Wes" <[e-mail]>]

Ron, et. Al:
I made a similar observation to Mike's about the amount of overlap between the drafts in v6ops this AM (http://www.ietf.org/mail-archive/web/v6ops/current/msg17431.html)
So how does draft-taylor-v6ops-fragdrop fit into this ? And for that matter, draft-andrews-6man-fragopt?
Apologies for not making the linkage on the first message, order of operations problem as I slogged through mail...

Could the authors (many of which also overlap) and WG chairs of one or both groups get together and sort out what is going where to address the issues, and map it to the (to be updated) drafts, identify to be abandoned drafts, etc? One cannot solve a problem of too many layers of abstraction with another layer of abstraction, and I fear we're headed in that direction with this group of drafts and all of the voluminous email threads discussing this set of problems all in one mass, across 2 WGs.
I vote for consolidating down to as few drafts as possible within the confines of the need to keep standards/protocol changes in 6man and address other procedural minutae.

Thanks,

Wes George

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Ronald Bonica
> Sent: Tuesday, August 20, 2013 9:34 AM
> To: C. M. Heard; IPv6
> Subject: RE: 6MAN WG Last Call: <draft-ietf-6man-oversized-header-chain-
> 04>
>
> Hi Mike,
>
> Thanks for your review of all three documents. The following is some
> gentle pushback.
>
> At IETF 87, the 6man WG was pretty clear that they are not ready to
> deprecate IPv6 fragmentation. So, within the next few weeks, I will
> update that document so that it makes only the following points:
>
> - IPv6 fragmentation doesn't work well because fragments are blocked on
> many paths
> - The IETF should not standardize any new protocols that rely on IPv6
> fragmentation
> - Some legacy protocols can break their reliance on fragmentation,
> others cannot. Legacy protocols that can break their reliance on
> fragmentation should consider doing so.
> - Legacy protocols and implementations thereof will continue to send
> fragments for a long time to come.
>
> Since fragmentation will be with us for a while, we need to deal with
> its issues. Currently, we see two issues:
>
> - the tiny fragment problem
> - the long header problem
>
> The two problems are orthogonal to one another. It is possible for a
> packet to display either problem without displaying the other.
>
> Also, there is a very concrete solution for the tiny fragment problem.
> This solution constitutes an UPDATE to RFC 2460 regarding sending and
> handling tiny fragments. Since we are updating 2460, we need to publish
> a PS document.
>
> There is no real solution to the long header problem. The best that we
> can do is to put a stake in the ground, saying that implementations
> should forward packets with header chains up to X bytes. There is no
> need to UPDATE RFC 2460, or to publish a PS document. A BCP is good
> enough.
>
> I hope that this helps.
>
>                                       Ron
>
>
>
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf
> Of
> > C. M. Heard
> > Sent: Monday, August 19, 2013 8:58 PM
> > To: IPv6
> > Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-oversized-header-
> > chain-04>
> >
> > Greetings,
> >
> > My main question is why this draft is not better integrated with
> > draft-wkumari-long-headers-01 and draft-bonica-6man-frag-deprecate,
> > which have overlapping or at least related subject matter.
> >
> > The thrust of draft-ietf-6man-oversized-header-chain is to require
> that
> > all extension headers and the upper layer header appear in the first
> > IPv6 fragment and to define an ICMPv6 error message that may be sent
> > when that condtion is violated (type = Parameter Problem, code = IPv6
> > first-fragment has incomplete IPv6 header chain).
> >
> > The thrust of draft-wkumari-long-headers-01 is the claim that
> operators
> > have a requirement to filter at Layer 3 and Layer 4, at line rate, in
> > the network, and that in order to be able to do that, the entire
> header
> > chain needs to appear within a relatively short initial segment of the
> > IPv6 datagram -- the draft suggests 128 bytes.  This is MUCH shorter
> > that the "within the first fragment"
> > constraint specified by draft-ietf-6man-oversized-header-chain.
> >
> > There is also a strong hint (though not an explicit statement) in
> > draft-wkumari-long-headers-01 that entities that do in-network line-
> > rate filtering need to see layer 3 and 4 information in ALL datagrams,
> > which is at the heart of the subject matter of draft-bonica-6man-frag-
> > deprecate.
> >
> > In my view, draft-ietf-6man-oversized-header-chain should not go to
> the
> > IESG until:
> >
> > 1.) This WG decides what to do with draft-bonica-6man-frag-deprecate.
> >     If the decision is to admit that IPv6 frgmentation works so
> >     poorly in pratice that new protocols must not use it and
> >     existing protocols should try not to use it, then a stronger
> >     recommendation than just confining the header chain to the
> >     initial fragment is probably in order -- perhaps something like
> >     what's in draft-wkumari-long-headers.
> >
> > 2.) This WG decides whether the ideas in draft-wkumari-long-headers
> >     are basically sound.  If so, then it would make sense (to me,
> >     anyway) to merge it with draft-ietf-6man-oversized-header-chain.
> >     The two drafts already agree (with admirable precision) on the
> >     definition of what a complete IPv6 header chain is.  One way to
> >     merge the documents would be to add a section to
> >     draft-ietf-6man-oversized-header-chain recognizing that there
> >     are likely to be stringent limits on the size of a header chain
> >     that an implementation can process and defining an ICMPv6 error
> >     message that may be sent when these limits are exceeded (type =
> >     Parameter Problem, code = IPv6 header chain exceeds
> >     implementation's capacity).  A recommendation on the minimum
> >     size header chain that an implementation should support would
> >     then be in order.
> >
> > Thanks,
> >
> > Mike Heard
> >
Anything below this line has been added by my company's mail server, I have no control over it.
-----------------

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.