On Wed, 4 Aug 2010 12:23:05 +0200, Rémi Després <remi.desp...@free.fr> wrote:
> Hi Fred, > > Le 4 août 2010 à 10:13, Fred Baker a écrit : > >> intellectually, end to end signaling might make sense. If so, it belongs >> in the end-to-end headers. > +1 > >> More importantly, who's using it? >> >> If using it end to end or end-to-network isn't being useful, either find >> a use, or deprecate it. > > RFC 3697, the current standard-track RFC on FLs, doesn't need IMHO to be > deprecated. > It only needs to be improved by relaxing two unnecessary and harmful > constraints (see below). > > Reasons to keep RFC 3697 are the following: > - The official purpose of FLs is to facilitate flow-dependent processing > in networks. > - At least draft-carpenter-flow-ecmp-02 describes a pragmatic use of such > FLs for load sharing among equal-cost paths. > - More generally, any load sharing application could take advantage of > these FLs, because they facilitate flow separation: > . With the help of FLs, two packets having different FLs are known to > belong to different flows. > . Without FLs, scanning complete extension-headers is necessary to find > out ports that identify individual flows (a complex task, and one that > becomes ineffective in case of datagram fragmentation). > > It is a fact that FLs are today generally set to 0 by sources. > But RFC 3697 requires in its section 3 a stateful and rather complex > construction of non 0 FLs. > This is bound to discourage host implementors as long as networks don't > use FLs. > Now, networks aren't permitted to set FLs themselves even if set to 0 by > hosts. > There is then a vicious circle where hosts wait for networks that wait for > hosts. > > The two modifications of RFC 3679 that may break the vicious circle are: > - Permit intermediate routers to set FLs in place of hosts if received = > 0. > - Permit hosts, and routers when they set FLs, to use simple hashes of the > 2- 3- or- 5-tuples that identify flows. (This stateless behavior could even > be recommended so that things are kept simple where there are no good > reasons to make them more complex.) > > I hope this isn't too long, but it is the best I can see on this subject. > Having a consensus in this direction would permit to leverage what exists > (rather than restarting from scratch), and to move on. > If this this approach is retained, I could contribute on detailed changes > to RFC 3679, with whoever is interested. I agree with this in principle, but there are still a few issues: - If the sending host sets FL=0, and an intermediate router resets it non-zero, the receiving host cannot determine whether the sending host or an intermediate router set the FL. This may break some e2e applications of the FL. - Permitting sending hosts to use a 2-5 tuple hash to set FL is fine, but it would better for my pet e2e use of the FL if the hash function was strongly recommended to be keyed, so that the hash is unpredictable. It will be awhile before hosts start setting FL non-zero, no matter what is decided. Addressing the first issue: for ECMP/LAG load balancing, where a router receiving a FL=0 packet would like to write a 5-tuple hash into FL, I don't think that the router needs to write more than 8 bits, because the downstream routers should still compute a <srcaddr, dstaddr, FL> hash to determine the load split. In this case, the router should write an 8-bit 3-tuple hash <protocol, srcport, dstport> into the FL. Given this assumption, *one* way to address the first issue is to set aside a range of FL label values that hosts never set and that routers can use, such as the following: - Hosts SHOULD set the FL pseudo-randomly in the range 0x00001 - 0xFFEFF (in line with RFC 3679, but permitting a keyed 5-tuple hash). - Routers receiving a packet with FL=0 are allowed to rewrite it pseudo-randomly in the range 0xFFF00 - 0xFFFFF. - Routers MUST NOT rewrite a non-zero FL in the range 0x00001 - 0xFFEFF. - Routers are not required to rewrite a non-zero FL in the range 0xFFF00 - 0xFFFFF to 0. - E2E applications of the FL should exclude received FL values in the ranges 0x00000, 0xFFF00 - 0xFFFFF. This is more complicated than I would prefer, but vastly preferable to dividing the FL into sub-fields IMHO. Regards, // Steve -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
