Subject: Re: Flow label drafts - updates, main open issue

From: Brian E Carpenter <[email-masked]>
Date: Mon, 07 Mar 2011 16:40:46 +1300

Hi,

I'm not hearing much in response to the open issue:

  Should we delete most of the text concerning stateful methods
  of handling the flow label?

In fact I'm not hearing much at all. Should I ask the WG Chairs
to conclude that everybody is OK with these drafts? That would
save us some time in Prague...

Regards
   Brian

On 2011-02-26 10:42, Brian E Carpenter wrote:
> Hi,
> 
> There are three updated flow label drafts:
> 
> 1. http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-3697bis-01.txt
> 
> This is the draft of the updated proposed standard for the flow label.
> The open issues discussed for the previous draft have been closed
> according to comments received - see the attached file for details.
> The authors believe that there is one big issue remaining:
> 
>   Should we delete most of the text concerning stateful methods
>   of handling the flow label? Basically that would mean deleting
>   Section 4 (and corresponding parts of the Security Considerations)
>   and making minor text adjustments elsewhere.
> 
> This would not mean that stateful methods are excluded for ever - it
> would just recognise that we are only sure of the stateless approach
> today.
> 
> 2. http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-update-03.txt
> 
> This draft is background rationale for the previous one, with minor
> updates to keep it in synch.
> 
> 3. http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-ecmp-01.txt
> 
> This is the ECMP/LAG draft updated according to WG Last Call comments.
> 
>    Brian + co-authors
> 
>

---

From: John Leslie <[email-masked]>
Date: Wed, 9 Mar 2011 10:48:37 -0500

>   of handling the flow label?

   I don't really have a horse in that race, but at first blush I'd say
the I-D goes into too much detail about stateful handling.

   IMHO, most handling (assuming it happens at all) will be stateless,
and will greatly resemble "damage" (as in what we route-around).

> save us some time in Prague...

   I won't be in Prague... :^(

   But while this I-D is a step in the right direction, where I think
we ought to get should allow much more leeway in setting -- even
changing -- Flow Labels _by_prior_arrangement_.

   The basic assumption that Flow Labels will be set by the sender and
passed unchanged is certainly correct in the absence of arrangements
that specify particular processing.

   I am a bit nervous about _always_ allowing a zero Flow Label to be
changed without sender consent...

   But clearly, there _can_ be no protection against such changes --
or any changes, for that matter.

   My intuition is that any time the Traffic Class is changed during
forwarding, rules about Flow Label particular to that Traffic Class
should apply.

   Further, there probably need to be _various_ largely out-of-band
mechanisms to validate a contractual basis for special handling of
packets based upon Flow Labels. There could be one or more in-band
mechanisms if we had what I'll call a "Middlebox Options" extension
header (between Hop-by-Hop and Destination Options) to store validation
information.

   Fundamentally, I don't believe the completely-insecure Flow Label
can serve by itself as sufficient justification for special handling;
and I don't believe that the sender alone can justify special handling
by _all_ the different service-providers along the forwarding path.
I think more infrastructure will need to evolve.

   Legislating what we can't specify any means to enforce isn't wise...

====

   Disclaimer: I in some sense "represent" the ConEx WG, where several
folks want to reserve one bit from the Flow Label for ConEx use. I am
_not_ the right person to put the case for that, because frankly I
don't agree with the idea. Nonetheless, it seems reasonable to me to
allow things like that on an Experimental basis if clearly labeled
by setting an Experimental Traffic Class.

--
John Leslie <[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Mar 2011 07:58:25 +1300

John,

In line comments...

> changing -- Flow Labels _by_prior_arrangement_.

The draft creates that leeway - apart from the Section 4 text about
stateful methods.
> forwarding, rules about Flow Label particular to that Traffic Class

There was considerable pushback in the WG to adding the concept
of local domains to the flow label definition.

> header (between Hop-by-Hop and Destination Options) to store validation

Yes, but that's in the stateful part that you're arguing above
should be replaced by "more leeway".

> I think more infrastructure will need to evolve.

Ditto.

> by setting an Experimental Traffic Class.

Ditto. What the draft is talking about is default behaviour, absent
anything requiring prior agreement or signalling.

I take your whole comment as a recommendation to remove section 4.

     Brian

---

From: Brian Haberman <[email-masked]>
Date: Fri, 11 Mar 2011 11:22:53 -0500

> I take your whole comment as a recommendation to remove section 4.

I would agree with removing section 4.  Without a defined stateful
mechanism anywhere on the horizon, it is reasonable to move forward
without that baggage.

Regards,
Brian