> > > > I had a preliminary idea and was going to write something > > > > about it. Basically the sender can generate the flow label > > > > based on a hash of the source and destination port numbers. > > > > This is straight forward enough. If we want to make it > > > > more sophisticated then we can add another number > > > > to the hash input (e.g P1 || P2 || x). > > > > Where x can be something specific to this flow. But > > > > I think P1 and P2 are enough. > > > > > > I guess this doesn't work where the source is setting up > > > flows to more than > > > one destination using the same source and destination port > > > numbers. So I > > > think you need to include destination address in the hash > > > computation as > > > well. > > > > => Well, there is no requirement that the flow label is > > globally unique. So this should work as long as you use > > a unique value between 2 addresses. > > > > However, it's only useful for a subset of cases,
=> I didn't really understand what you mean by 'subset of cases'. so I don't think > it affects the basic definition in the draft. > => Not at all, it's not meant to affect the basic definition in the draft, on the contrary it's meant to complement it. I actually like the draft's proposal. Hesham > Brian > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
