Re: [v6ops] draft-taylor-v6ops-fragdrop WGLC

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

As to whether this is ready for IETF LC or should be adopted by the WG, no it's not ready, and I don't know if it should be adopted. Specifically, I think that guidance for implementers about use of fragments is useful, especially in documenting current behavior on the network and the justifications for it. However, we're starting to get a lot of overlap between the drafts dealing with fragmentation, whether it should be deprecated, whether we should simply provide a caveat implementer statement on using fragments but leave the standard alone, etc. It makes matters worse when one considers fragmented packets together with large headers, since at least some of the technical considerations overlap. To avoid confusion, I think we need to decide which direction we want to go before advancing drafts on the matter. If indeed we want implementers to read and heed the advice in this draft (or other related drafts), we should make sure we have a cohesive message. Right now we have justifications and operational observations spread across at least this draft and draft-bonica-6man-frag-deprecate (which I'd argue discusses the operational considerations much more robustly than this document), and possibly even draft-generic-6man-tunfrag.

Some specific comments on the draft, if indeed I'm in the minority and this advances:

General grammar pedantry nit - there's a good bit of passive voice in this draft, most of which could be eliminated through rewording.

Intro:
"The filtering of IPv6 datagrams with fragmentation headers is
   presumed to be a non-issue in the core of the Internet, where
   fragments are routed just like any other IPv6 datagram. here
   fragments are routed just like any other IPv6 datagram.  However,
   fragmentation can creates operational issues at the edges of the
   Internet"
This is unclear. Use fewer words. I think what you're trying to say is that "the core doesn't commonly filter fragments, but the edge does, and that creates operational issues".

2.1 - as others have said, the last sentence needs to be explained. This is probably the place to add a reference to one or more of the drafts I mentioned above rather than rehash it. (assuming that you don't end up incorporating much of draft-bonica section 2 into this draft, such that draft-bonica can simply recommend deprecation of fragmentation using this draft as a foundation)

2.1.3 - if this document wishes to remain neutral, I'd recommend that you drop the transition/intro text "Leaving aside these incentives towards fragment dropping". It's not really adding anything, and "these incentives" is somewhat unclear anyway.

2.1.4 - control plane ACLs only affect traffic destined *to* the router, not through it. It would be better to make that clearer. "drop all fragments" is misleading as currently written.

2.2 - folks have raised this point in discussion of the other fragmentation drafts, but there are also legitimate uses for fragmentation when dealing with data links that cannot support IPv6's minimum MTU of 1280. Some data links will do their own fragmentation to compensate, others expect the IP layer to do it.


A reference to RFC 6980 might also be useful, though I'm not certain where it would best fit.

Thanks,

Wes George

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.