Subject: [Fwd: I-D Action:draft-carpenter-6man-flow-update-04.txt]

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Sep 2010 12:03:58 +1200

Hi,

This is yet another substantial rewrite following the recent
discussions on the list (and some off the list). Please read
it with new eyes - a diff from the previous version will not
be very helpful.

Also, there's now a 3rd author.

  Brian, Sheng, Shane

-------- Original Message --------
Subject: I-D Action:draft-carpenter-6man-flow-update-04.txt
Date: Thu, 16 Sep 2010 16:30:02 -0700 (PDT)
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Update to the IPv6 flow label specification
	Author(s)       : S. Amante, et al.
	Filename        : draft-carpenter-6man-flow-update-04.txt
	Pages           : 13
	Date            : 2010-09-16

Various published proposals for use of the IPv6 flow label are
incompatible with its existing specification in RFC 3697.
Furthermore, very little practical use is made of the flow label,
partly due to some uncertainties about the correct interpretation of
the specification.  This document proposes changes to the
specification in order to clarify it, making it clear what types of
usage are possible, and to introduce some additional flexibility.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-carpenter-6man-flow-update-04.txt

---

From: "Dale W. Carder" <[email-masked]>
Date: Thu, 16 Sep 2010 21:37:37 -0500

> it with new eyes - a diff from the previous version will not

Is there a reason that hosts/nodes couldn't set the flow 
label to a site-specific value (and likely not pseudo-random)
especially considering that the value may/will be cleared at 
administrative boundaries?

In RFC 3697, #3 Flow Labeling Requirements, it says that the
source node can use a well defined sequence like incrementing 
values, whereas the emphasis in the draft is on pseudo-randomness.

If I've missed that discussion, I apologize.

Dale

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Sep 2010 15:45:39 +1200

Dale,

> administrative boundaries?

Well, the reaction from the WG to earlier versions proposing
a local-use model were quite negative. There are many messages
in the archive about that.

> values, whereas the emphasis in the draft is on pseudo-randomness.

Correct.  A message I got from the discussion was that operators
are quite eager to find viable load balancing methods, and that
pseudo-random labels are useful for that. The other message was
that the present completely open spec has had the perverse result
that nobody has implemented anything at all.

    Brian

---

From: Shane Amante <[email-masked]>
Date: Fri, 17 Sep 2010 10:07:00 -0600

Hi Dale,

> administrative boundaries?

The usual saying applies: "your network, your rules".  HOWEVER, when[1] site-specific (a.k.a.: locally-defined) flow-label escapes beyond an administrative boundary and downstream routers (in other ASN's) are using flow-labels as input-keys for LAG and/or ECMP load-balancing (as recommended by this draft), then there a few potential consequences (which may not be coming out as clearly as they should in the present -04 draft):
1)  Your traffic flows through those downstream networks could result in non-determinisitic forwarding behavior if the flow-labels that are being used were not, as per Rule #1 in the draft, both pseudo-random AND a consistent/persistent value per-"flow".  (See Section 3 for a definition of "flow").
2)  If there is a hope, or expectation, (and, I hope there is) that flow-labels could be used to detect & potentially mitigate third-party DDoS or MiTM attacks at receiving hosts (or, firewalls/middleboxes), then your site-specific flow-labels could potentially results in dropped packets or transport sessions being reset.  Obviously what should, could or will happen is still TBD since both draft-blake and draft-gont are, IMHO, still in their 'formative' stages.

The one "saving grace," as it were, is Rule #3.1:
       1.  A forwarding node acting as a domain border device MAY be
           configured to set the flow label value in incoming packets to
           the default value of zero.
... allows downstream ASBR's, firewalls, etc. to reset the flow-label to 0 to fix "broken" upstream networks that are leaking site-specific flow-labels.  However, that downstream ASBR, firewall, etc. would first need to detect broken flow-labels are being used, which IMO, would be quite challenging, at best, in order that an operator would be prompted to login and configure such a thing.  Of course, if this were just a default action on ASBR's and FW's, (always resetting to 0), then we're no better off than where we are today.

In short, don't do it (please).  :-)

> values, whereas the emphasis in the draft is on pseudo-randomness.

I think Brian already answered this.

> If I've missed that discussion, I apologize.

No worries.

Thanks!

-shane

[1] Even with the best of intentions, bugs and misconfigurations (intentional or accidental) do happen.  :(
[2] Dropped packets if the LAG and/or ECMP hash algorithm is putting, say, ALL of your flows onto a single component-link of a LAG or ECMP path causing congestion.  Or, packets could potentially get reordered if, for example, the flow-label was inconsistent on a per-packet basis which would cause packets of the same flow to be sprayed on different component-links of a LAG or ECMP path with different queue depths.

> Dale
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Fri, 17 Sep 2010 15:01:44 -0300

Hi, Brian,

I've read the document and I'm happy with this rev. Some minor comments:

* Section 4 says:

>    2.  A node that forwards a flow whose flow label value in arriving
>        packets is zero MAY set the flow label value.  In that case, it
>        is RECOMMENDED that the forwarding node sets the flow label field
>        for a flow to a pseudo-random value.

While I know this is the intention of the text, I'd clarify that if they
rewrite a zero flow-label, they should do so consistently (i.e., all
packets of a given flow are rewritten with the same FlowLabel value).

* Section 4 says:

>        2.  A network domain MUST NOT forward packets outside the domain
>            whose flow label values are other than zero or pseudo-random.

Although I don't feel strongly about what I'm going to say, maybe s/MUST
NOT/SHOULD NOT"? Strictly speaking, the FL is an optimization, and is
not expected to cause interoperability issues....

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 18 Sep 2010 08:17:36 +1200

Hi Fernando,

> packets of a given flow are rewritten with the same FlowLabel value).

Yes, that is said very clearly in RFC 3697 and does not change.

> not expected to cause interoperability issues....

Well, this is a matter of taste; it's really trying to say
"what happens in Las Vegas, stays in Las Vegas", as far as the
flow label goes. Let's see what the rest of the WG thinks.

Thanks!

    Brian

---

From: Rémi Després <[email-masked]>
Date: Fri, 17 Sep 2010 22:31:09 +0200

Le 17 sept. 2010 à 20:01, Fernando Gont a écrit :
> .., I'd clarify that if they

+1, and more generally having all the same constraints as for the initial setting.

>>           whose flow label values are other than zero or pseudo-random.

+1 for the MUST, which in part relates to the first point above.

Regards,
RD

---

From: Fernando Gont <[email-masked]>
Date: Fri, 17 Sep 2010 21:22:20 -0300

Hi, Brian,

> Yes, that is said very clearly in RFC 3697 and does not change.

Agreed. But just reading *this* doc it wasn't so clear (yes, implied,
but even better if it was more explicit for this particular case).

Thanks!

Kind regards,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 17 Sep 2010 21:24:33 -0300

> +1, and more generally having all the same constraints as for the initial setting.

Exactly.

Thanks,