Hi, Remi, Thanks for your summury. They are is quite right.
I agree a new and simple document that obsolete RFC 3697 could be bette approach. Now, the urgency is to make sure the WG agrees on these proposed changes. After than, how we move forward could also flow the WG's consensus. Cheers, Sheng > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] > Sent: Thursday, April 15, 2010 5:59 AM > To: Rémi Després > Cc: Sheng Jiang; 6man > Subject: Re: [Fwd: New Version Notification for > draft-carpenter-6man-flow-update-02] > > Rémi, > > Thanks for the analysis. Indeed, the conclusion may be, > assuming the WG is interested at all, that a complete refresh > of RFC 3697 is better than publishing a delta. > > I agree that it is a bit complicated to explain, although the > underlying concept is quite clear: allow local use of the > flow label, but also enable global use. I also think we were > too careful in RFC 3697 - if we had unambiguously recommended > a pseudo-random label per flow, it might already be used for > load balancing. (By the way, there will soon be an update of > draft-carpenter-flow-ecmp, adding the LAG case and a second > author, which I think will make the load balancing use case > very clear.) > > Thanks > Brian > > On 2010-04-15 04:06, Rémi Després wrote: > > Brian, Sheng, > > > > I carefully read the draft, and read again RFC 3697 and > draft-carpenter-6man-flow-update-02. > > The draft is IMHO overly hard to understand but, unless I > misunderstand its intent (which is quite possible), I > appreciate what it proposes. > > I do support the intent, but feel uncomfortable with how it > is introduced. > > > > In my understanding: > > A) The essential changes are: > > A1. Flow Labels MAY be changed within the network, instead > of "MUST be delivered unchanged". > > A2. Nodes that set Flow Labels MAY apply local policies, > including stateless ones, instead of "SHOULD select new Flow > Label values in a well-defined sequence (e.g., sequential or > pseudo-random". > > B) The essentials of what is kept are: > > B1. Where Flow Labels are set, their values MUST be the > same for packets that have the same 5-tuples (or 3-tuples), > and are separated by less than 120s. > > B3. For flow-based routing optimization to be possible, > Flow Labels should in general be given different values for > different 5-tuples (or 3-tuples) that share the same > source-address/destination-address couples. > > > > If this makes sense, I am convinced that it would be better > to propose a clear and simple new RFC, and obsolete RFC 3697. > > Trying to complement RFC 3697 with what amounts to a > significant change is in my understanding bond to be awkward. > > > > Thoughts? > > > > Kind regards, > > RD > > > > > > > > Le 14 avr. 2010 à 06:48, Brian E Carpenter a écrit : > > > >> Hi, > >> > >> This is completely revised from the proposal we presented > in Anaheim. > >> This version allows locally defined use of the flow label in a > >> simpler way, as the discussion suggested. > >> It's still quite a dense read, but we believe that if this was > >> adopted, it would open the way to actually using the flow label. > >> > >> Brian and Sheng > >> > >> -------- Original Message -------- > >> Subject: New Version Notification for > >> draft-carpenter-6man-flow-update-02 > >> Date: Tue, 13 Apr 2010 21:44:42 -0700 (PDT) > >> From: IETF I-D Submission Tool <idsubmiss...@ietf.org> > >> To: brian.e.carpen...@gmail.com > >> CC: shengji...@huawei.com > >> > >> > >> A new version of I-D, draft-carpenter-6man-flow-update-02.txt has > >> been successfully submitted by Brian Carpenter and posted > to the IETF repository. > >> > >> Filename: draft-carpenter-6man-flow-update > >> Revision: 02 > >> Title: Update to the IPv6 flow label specification > >> Creation_date: 2010-04-13 > >> WG ID: Independent Submission > >> Number_of_pages: 10 > >> > >> Abstract: > >> Various uses proposed for the IPv6 flow label are > incompatible with > >> its existing specification. This document describes > changes to the > >> specification that permit additional use cases as well as allowing > >> continued use of the previous specification. > >> > >> > >> > >> The IETF Secretariat. > >> > >> > >> > >> > -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> > -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
