nanog mailing list archives

Re: L3DSR server side bits open sourced


From: Shane Amante <shane () castlepoint net>
Date: Wed, 9 Mar 2011 08:12:53 -0700


On Mar 9, 2011, at 00:35 MST, Igor Gashinsky wrote:
On Wed, 9 Mar 2011, Randy Bush wrote:

:: a real use for the diffserv bits!  why not flowlabel in 6?  it's been
:: looking for a use for a decade.

Honestly, we figured flowlabel might actually find a use before all the
values of diffserv will :) In all seriousness, we are starting to set the 
spec for v6 l3dsr now, so, if you care, and believe that flowlabel would 
be a better field to "hijack" (or have a suggestion for another, better 
way then same DSCP methodology that we used for ipv4), we welcome input..

:-/  Please don't abuse the flow-label this way, otherwise your proposal could get added to the "graveyard of IPv6 
flow-label proposals" draft:
http://tools.ietf.org/html/draft-hu-flow-label-cases-03#section-3

There has been *a lot* of discussion in the 6man WG recently to (finally) define the flow-label to be: a) be stateless; 
and, b) potentially be useful as an input-key, when used in conjunction with {src_ip, dst_ip}, for fine-grained 
load-balancing over LAG & ECMP paths, (instead of the traditional IPv6 header 5-tuple).  One example where this might 
be useful is within Layer-2 switches, at IXP's or other parts of the network, where you'd really like them to only have 
to look at the 3-tuple: {src_ip, dst_ip + flow-label} as input-keys for LAG load-balancing, since they are at a fixed 
location in the IPv6 header.  The other, longer-term win of this approach is that hosts can be free to define, or 
re-define, new IPv6 Extension Headers and you won't have to worry about Core routers/switches needing to dig into those 
Ext. headers (or, past them) to find useful input-keys for load-balancing over LAG & ECMP paths.

Take a look at the following drafts and comment on the 6man WG mailing list if you have questions or concerns:
IPv6 Flow Label Specification -- proposed revisions to the most current (& confusing) flow-label RFC:
http://tools.ietf.org/html/draft-ietf-6man-flow-3697bis-01

Using the IPv6 flow label for equal cost multipath routing and link aggregation in tunnels
http://tools.ietf.org/html/draft-ietf-6man-flow-ecmp-01

Rationale for update to the IPv6 flow label specification
http://tools.ietf.org/html/draft-ietf-6man-flow-update-03

-shane

Current thread: