Subject: Re: I-D Action: draft-baker-ipv6-ospf-dst-flowlabel-routing-01.txt

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 May 2013 08:12:45 +1200

Yes, I know which WG this is, and I would like to test a
hypothesis here: that the draft below is incompatible with
RFC 6437 (and the long discussion that led to it).

The problem, if there is one, lies in section 4 of RFC 6437.

>    A node that sets the flow label MAY also take part in a flow state
>    establishment method that results in assigning specific treatments to
>    specific flows, possibly including signaling.  

That's OK - nodes using -ospf-dst-flowlabel-routing would be doing that.

>    Any such method MUST
>    NOT disturb nodes taking part in the stateless scenario just
>    described.  Thus, any node that sets flow label values according to a
>    stateful scheme MUST choose labels that conform to Section 3 of this
>    specification.  Further details are not discussed in this document.

That's the bit that -ospf-dst-flowlabel-routing does not conform to, as
far as I can see.

Regards
   Brian

On 03/05/2013 06:39, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title           : Using OSPFv3 with Role-Based Access Control
> 	Author(s)       : Fred Baker
> 	Filename        : draft-baker-ipv6-ospf-dst-flowlabel-routing-01.txt
> 	Pages           : 10
> 	Date            : 2013-05-02
> 
> Abstract:
>    This note describes the changes necessary for OSPFv3 to route classes
>    of IPv6 traffic that are defined by an IPv6 Flow Label and a
>    destination prefix.  This implies not simply routing "to a
>    destination", but "traffic going to that destination AND using a
>    specified flow label".  It may be combined with other qualifying
>    attributes, such as "traffic going to that destination AND using a
>    specified flow label AND from a specified source prefix".  The
>    obvious application is data center inter-tenant routing using a form
>    of role-based access control.  If the sender doesn't know the value
>    to insert in the flow label (the receiver's tenant ID), it in effect
>    has no route to that destination, thus providing an access list that
>    is as changeable and scalable as routing.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-baker-ipv6-ospf-dst-flowlabel-routing
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-flowlabel-routing-01
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-baker-ipv6-ospf-dst-flowlabel-routing-01
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 2 May 2013 20:37:46 +0000

> That's the bit that -ospf-dst-flowlabel-routing does not conform to, as

It may be so. Can you point me to an implementation depending on 6437, either host, router, or load balancer?

Here's my frustration. The Flow label, if one goes into the musty dusty mists of time, does not do what it was originally designed to do, which is identify flows in the Nimrod routing model; to do that, it would need to be fungible in the network. It has been largely replaced by MPLS, which can stack its equivalent. As you know (you wrote half of them), there are a several RFCs that propose uses of the flow label, and those uses differ from each other. None of them obsolete the others, so they are all on the table.

You are taking one in that series and pushing it as the "one true religion", and stating that it is therefore off limits to use the flow label for a specific well defined use case.

I call foul. If RFC 6437 is the only game in town, at least obsolete RFCs 1809 and 6294, and the section proposing a use case for it in 2460.

And explain to me why it would be inappropriate for a host (virtual or physical) or a hypervisor to set a flow label and use it end to end for a specific use case in a data center?

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 May 2013 09:17:59 +1200

> It may be so. Can you point me to an implementation depending on 6437, either host, router, or load balancer?

No, but it's too recent - implementers have to look at the newest Node Requirements
and then do their product cycle thing. For load balancers, there's an Informational
draft wending its way through the system.

> Here's my frustration. The Flow label, if one goes into the musty dusty mists of time, does not do what it was originally designed to do, which is identify flows in the Nimrod routing model; to do…

I agree. That's why I've invested considerable effort myself.

> You are taking one in that series and pushing it as the "one true religion", and stating that it is therefore off limits to use the flow label for a specific well defined use case.

Well, there was a two year debate in 6man before we reached rough consensus.
That's all I know how to do. However, there is intentional wiggle room
in the RFC and maybe we can reconcile things; I'd like other peoples'
eyes on the that question. For compatibility with load balancing, all
we really need is pseudo-random bits - if the way of setting up
destination labels in your proposal could do that, it's probably fine.

> I call foul. If RFC 6437 is the only game in town, at least obsolete RFCs 1809 and 6294, and the section proposing a use case for it in 2460.

I thought we did obsolete those bits of 2460. iirc they were non-normative anyway.
1809 is informational; I've never thought of it as needing to be obsoleted.
6294 is purely descriptive, so I don't see why it's an issue.

> And explain to me why it would be inappropriate for a host (virtual or physical) or a hypervisor to set a flow label and use it end to end for a specific use case in a data center?

I don't think it would, but this WG disliked the concept of defining
a local flow label domain and it was dropped from what became RFC 6437.
That's why I think the way out is to use the wiggle room mentioned
above. I hope we can.

   Brian

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 2 May 2013 21:24:52 +0000

> That's why I think the way out is to use the wiggle room mentioned

I'm afraid I don't see any wiggle room. Section 3 of RFC 6437 requires every new flow - every new TCP session, in the most extreme reading of that - to have a new flow label value. This proposal presumes that all of the flows subject to the same security policy would be identified by the same flow label. By your rubric, an operator who is not using the flow label for load balancing MUST NOT use the flow label for a different purpose. Frankly, I wish you luck enforcing the ruling. Operators have a funny habit of doing what they deem important. Our job in the IETF is to help them be able to do that using software and hardware from multiple interoperable sources.

---

From: joel jaeggli <[email-masked]>
Date: Thu, 02 May 2013 14:35:07 -0700

> I'm afraid I don't see any wiggle room. Section 3 of RFC 6437 requires every new flow - every new TCP session, in the most extreme reading of that - to have a new flow label value. This proposal pr…
I've been uncomfortable with the attempts to rehabilitate the flow label 
since they seem to be inconsistent. I can't do something useful if 
that's largely unusable due to host behavior, if I keep changing what 
the hosts are doing with it.

If I can resuse it without the hosts changing their behavior, great 
especially if it's within my own span of control. but then I don't 
really need ietf consensus for that.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 May 2013 09:37:22 +1200

Read the first paragraph of the Introduction carefully, in connection
with the SHOULD in the second paragraph of section 3.

You could definitely provide a good reason for bypassing that SHOULD.

Regards
   Brian

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 2 May 2013 21:45:37 +0000

> You could definitely provide a good reason for bypassing that SHOULD.

Fine. I'll point to that and say that this is a different use case.