Subject: Fwd: New Version Notification for draft-wkumari-long-headers-00.txt

From: Warren Kumari <[email-masked]>
Date: Wed, 20 Feb 2013 14:44:41 -0500

Hello all,

We wanted to make you aware of a document we submitted a while back --unfortunately *someone*[0] forgot to put -6man- somewhere in the title.

This document explains issues that *operators* have with "long header chains" and devices that need to see the L4 information.

We understand that this is likely to be a controversial document, and will spark lively discussion[1]. 

W

[0]: Ok, it was me…
[1]: AKA Nomex underwear time.

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-wkumari-long-headers-00.txt
> Date: February 4, 2013 10:07:59 AM EST
> To: [email-masked]
> Cc: [email-masked], [email-masked]
> 
> 
> A new version of I-D, draft-wkumari-long-headers-00.txt
> has been successfully submitted by Warren Kumari and posted to the
> IETF repository.
> 
> Filename:	 draft-wkumari-long-headers
> Revision:	 00
> Title:		 Operational Issues Associated With Long IPv6 Extension Header Chains
> Creation date:	 2013-02-04
> WG ID:		 Individual Submission
> Number of pages: 9
> URL:             http://www.ietf.org/internet-drafts/draft-wkumari-long-headers-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-wkumari-long-headers
> Htmlized:        http://tools.ietf.org/html/draft-wkumari-long-headers-00
> 
> 
> Abstract:
>   This document outlines a set of issues with the use of long IPv6
>   extension header chains.  It considers their use in the context of
>   today's IPv6 Internet and potential interaction with forwarding
>   devices that require upper-layer headers.
> 
> 
> 
> 
> The IETF Secretariat
> 

--
Do not meddle in the affairs of dragons, for you are crunchy and taste good with ketchup.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Feb 2013 12:55:38 +0000

Hi,

I suggest that the draft should focus only on describing the operational
issues with as much precision as possible. It's only the last paragraph
of section 3 and the brief section 4 that will be controversial, and
as always it's best to start with the facts, all the facts, before
reaching conclusions.

A missing topic is load balancers, where the issue is of considerable
importance. There's some discussion of the extension header issue
in draft-ietf-intarea-flow-label-balancing.

I'm surprised there's no reference to draft-ietf-6man-oversized-header-chain.

Regards
   Brian

On 20/02/2013 19:44, Warren Kumari wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Warren Kumari <[email-masked]>
Date: Thu, 21 Feb 2013 10:30:50 -0500

> as always it's best to start with the facts, all the facts, before

Yup. The conclusion isn't (yet!) "Long headers are hard, let's just deprecate them" -- the draft is intended to explain the problems, start discussions and make folk aware of the fact that a number of folk are dropping these sorts of packets. 

The last parts of the draft are there for a few reasons:
1: Drafts that simply say "Here is an issue" without bothering to propose any sort of solution always feels (to me at least) as though the authors haven't bothered and are expecting someone else to solve all their issues for them….

2: This is a strawman proposal -- it is (IMO) easier to discuss the issues if there is a proposal. This may not be *the* solution, but at the moment it is at least something we can use for discussions / poke holes in. We did discuss at length what all solutions there could be, and they went something like this:

a: the network should never have to look at L4 info / look past the IP / HbH bits --- unfortunately this misses real world requirements (which we reed to capture in the draft)

b: hardware vendors should simply solve the architectural / performance issues  -- this required too much pixie dust. It also doesn't solve the issue of already deployed boxes.

c: L4 info could be copied to *just* after the IP header (and then some handwaving to make sure that the L4 info here matches the L4 info in the upper-layer protocol) -- this has many issues..

d: what we suggested / formally deprecating all headers 

e: hopefully the IETF / 6MAN will point at some really obvious solution and we can breath a sign of relief and abandon the draft.

3: Having something slightly controversial sparks discussion and helps to get folk involved :-P

> I'm surprised there's no reference to draft-ietf-6man-oversized-header-chain.

Yup, both of those were an oversight, for which I apologize -- oversized-header-chain was referenced, but got eaten during an 'svn merge' that wen't horribly wrong (which also ate the -6man- in the title). Not referencing / discussing draft-ietf-intarea-flow-label-balancing was simply a stupid omission. 
I'm sure y'all know how it goes -- you start writing a draft with much energy, then $DayJob gets in the way… Suddenly you realize that the next meeting is fast approaching, and you scurry to get everyones text in. For some reason this always happens during some other crisis and you forget something important…

W

--
"Real children don't go hoppity-skip unless they are on drugs."

    -- Susan, the ultimate sensible governess (Terry Pratchett, Hogfather)

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Feb 2013 17:07:25 +0000

> 1: Drafts that simply say "Here is an issue" without bothering to propose any sort of solution always feels (to me at least) as though the authors haven't bothered and are expecting someone else to…

Sure, but a proposal that removes a major part of the design of IPv6
simply can't fly right out of the box (excuse my metaphor).

...
> b: hardware vendors should simply solve the architectural / performance issues  -- this required too much pixie dust. It also doesn't solve the issue of already deployed boxes.

I suspect that there are solutions that don't need pixie dust, but which
do require product redesign, and the IETF often enough calls for product
redesign. Anyway... I do think that discussion is premature.

   Brian