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 <[email protected]> >> To: [email protected] >> CC: [email protected] >> >> >> 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 >> [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 --------------------------------------------------------------------
