Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Suresh Krishnan Sent: Thursday, October 28, 2010 9:01 AM To: Rémi Després Cc: 6man 6man; George, Wes E IV [NTK]; Guolinag Yang; Yiu Lee; Christian Huitema; Brian Carpenter Subject: Re: I-D Action:draft-krishnan-6man-header-reserved-bits-00.txt Hi Remi, On 10-10-28 02:50 AM, Rémi Després wrote: > Le 28 oct. 2010 à 07:18, Suresh Krishnan a écrit : > >>>>> ... >>>> I doubt that any new use of the flow label will be backward compatible. Do you have any text about this proposal that I can read up on? >>> In my understanding: >>> - draft-carpenter-flow-ecmp-03 details a promising particular use of 20-bit FLs that wasn't detailed before (Flow Label for tunnel ECMP/LAG) >>> - it can work with the current rules about flow-label settings, but >>> too few hosts, if any, set FLs to non-zero values today >>> - this is, at least in part, due to the fact that these rules are >>> more complex that needed: stateful processing is required, or "seems" to be required (there is a debate), while algorithmic hashes would be easier to implement in hosts and sufficient for load balancing purposes. - draft-zhou-softwire-ds-lite-p2p-02 describes a new use of 20-bit FLs (Deployment DS-lite in Point-to-Point Access Network) >>> - it remains backward compatible with current rules because it is >>> only between point-to-point tunnel endpoints, i.e. without relationship with host FL settings. >>> If one of these proposals would fail with hosts that support current rules for FL settings, it couldn't be claimed that they are backward compatible, but I have personally identified no such incompatibility. >> The proposals need consenting hosts on both ends to be useful, don't they? > > They don't! > (Load balancing is a one-way function. If a host sets FLs, its flows > to all destinations can be load balanced with ecmp, independently of what other ends do.) For one-way functions, it should not matter if one side thinks of these 20 bits as two different fields (4+16) and the other as a single 20 bit field, right? I agree with the goals you have stated in this thread, but I am trying to figure out *what exactly breaks* because of shortening/splitting out the field. And this one-way quality is certainly not true of the other work (draft-zhou) that you mentioned that requires that the Flow Label be be mated to the NAT binding on one side and to the point-to-point link id on the other side. > >>> .... >> My point was, if we need to change the nodes at both ends to >> implement a new use of the flow label, the backward compatibility argument is moot. > > Right "if we need to change the nodes at both ends", but we don't. As I said before, for draft-zhou, we need to. [Suresh, thank you for taking time reading draft-zhou. As the author, I dont see why we need to modify the Flow label at both ends in draft-zhou. Why do you say that? Whats the technical reason? Thanks.] Thanks Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
