On 03/05/2013 08:37, Fred Baker (fred) wrote: > On May 2, 2013, at 1:12 PM, Brian E Carpenter <brian.e.carpen...@gmail.com> > wrote: >>> 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. > > 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 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. 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
