[138530] in North American Network Operators' Group
Re: L3DSR server side bits open sourced
daemon@ATHENA.MIT.EDU (Shane Amante)
Wed Mar 9 10:13:45 2011
From: Shane Amante <shane@castlepoint.net>
In-Reply-To: <Pine.LNX.4.64.1103090227410.16760@moonbase.nullrouteit.net>
Date: Wed, 9 Mar 2011 08:12:53 -0700
To: Igor Gashinsky <igor@gashinsky.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Mar 9, 2011, at 00:35 MST, Igor Gashinsky wrote:
> On Wed, 9 Mar 2011, Randy Bush wrote:
>=20
> :: a real use for the diffserv bits! why not flowlabel in 6? it's =
been
> :: looking for a use for a decade.
>=20
> 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=20
> spec for v6 l3dsr now, so, if you care, and believe that flowlabel =
would=20
> be a better field to "hijack" (or have a suggestion for another, =
better=20
> 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=
